Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Caution この記事はDHHファンの妄想によるシナリオが多分に含まれます。 というかほとんどです。 成り立ちが間違ってることも当然あるように思うので話半分で読んでください。 これは一体 最近のRailsフロントエンドやDHHの活動には一連の流れがあるわけですが、一部トレンドに沿ってない部分がある故にそれが汲めないというところがあるのではと思います。 それらの流れを記憶が定かなうちにつないで記録しておこうという記事です。 前提知識 Railsの生みの親、Rubyist Basecamp(社) DHHがCTOやってる会社 Basecamp(サービス) Basecamp(社)が開発してるプロジェクト管理ツール Trixを開発してたある日 Basecamp(サービス)に組み込まれてるリッチテキストエディタのtrixをcustomElements使って開発してたある日、DHHはあることに気づく。
「正直9年経ったいまでもfor文ググってる」 という議論記事があった。正直なところ私もググる方の人だ。私の感想: ポンとテキストエディタだけ渡された時に書けるか自信ないぞ...IDEがあればまあ大丈夫かなあ。 JavaScriptだけじゃない。言語色々扱うしという言い訳。正規表現とか毎度調べる。 だから世の中にチートシートというものがあるのだ。お気に入りチートシート多数。 実戦でどうしているか?結局周りのソースを見て馴染む書き方にしていますよ多分。 暗記するかしないかは受験勉強みたいなもので、コーディング面接に受かるなら必要。暗記そのものには意味はないとは思う。 競技プログラミングが使えないとかいう論もあったな。 ググり力も大事。 でも「最低限」もできないのはやはり恥ずかしい気持ちはある。 なんかこれ英語できるできないと似てるな。英語なんてGoogle翻訳、DeepL翻訳あればいいけど、実
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 伝えたいことは全てタイトルに書いた。 動機 https://github.com/topics/awesome を眺めていて本当にawesomeなものばかりだった (割にあまりどこにもそのawesomeさが書かれていないように見えた) ので書く。 awesomeリストとは GitHub で使われる慣習的なリポジトリについてまとめてみた#awesome より: 「特定テーマに関するキュレーションを行うリポジトリ。Markdown のリスト表記で一覧化するのが一般的。また、Contribution も受け付けている(人気のあるリポジトリはガ
こんにちは。株式会社ビットジャーニーでエンジニアをしてる@pockeです。 ビットジャーニーではKibelaというWebアプリケーションを開発しています。 KibelaではPublicなWeb APIにGraphQLを使用して提供しています。 https://github.com/kibela/kibela-api-v1-document また、このAPIはKibelaのWebアプリケーションの内部でも同じものが使用されています。 先日、このGraphQL APIを自動的に(ある程度)網羅的にテストするためのgem graphql-autotestをリリースしました。 https://github.com/bitjourney/graphql-autotest この記事ではこのgraphql-autotestを紹介します。 なおgraphql-autotestはRubyで書かれていますが、
前置き すごく手間のいる作業が存在していた。ざっくり スプレッドシートを複製 運用管理ツールからjsonを複数DL シミュレータ実行 シミュレータ実行結果をスプレッドシートに貼り付け 目視で結果確認(NGならリトライ) スプレッドシートからExcelファイルexport メール&Slackで報告 実質的な作業時間としては10~20min(リトライあるともっと)かかるが、色んなツールが必要だからとにかく面倒。 図にするとこんな感じ 環境 masOS Mojave ver10.14.6 Python 3.7.3 pip 19.2.2 激効率化(自動化)した結果 パラメータ指定なしのコマンド一つで、欲しかったExcelファイルが作成されるようにした 自動化のポイント 1. 運用観点 無駄は無くしていこうな方針で2点対応。 1-1. スプレッドシートの廃止 シミュレート結果の確認+Excelファイ
まえがき yield ってなにがどうなっているのか (yeildが使われているコードの説明で) 自分で書くとこの設計できないのよね こんな感想をいただきました yield の理解を深めてもらうために、こんな使い方をしているよというコードベースでご紹介していきます 対象読者 yield がよくわからない人 yield がわかっているけど、自分の書くコードで使ったことがない人 yield ユースケース パフォーマンス監視 処理時間を記録して報告するような機能 module XXXReportable def with_reporting(name: ) started = Time.zone.now yield ended = Time.zone.now report(name: name, started: started, ended: ended) end private def rep
Rubyにpipeline operator(以下pipeline演算子)が導入されると話題になっているようです(【速報】Ruby の trunk に pipeline operator がはいった, Twitterでの検索結果、など)。 残念ながら私はRubyがほとんどわからないので、代わりにJavaScript(この場合ECMAScriptと呼ぶべきですが)に提案されているpipeline演算子についてまとめてみようと思います。 pipeline演算子の現状について JSのpipeline演算子はまだ正式に導入されたわけではなく、いわゆるStage 1と呼ばれる状態で、まだ仕様自体しっかり固まっていない状態です(Stageについてはこちらがわかりやすいです)。 そのため、将来的に本記事の内容とは違う文法・仕様になっている可能性もあるため、ご注意ください。 更に、pipeline演算子の
先日リリースされたRuby2.6で標準ライブラリに取り入れられたBundlerですが、2019年1月3日にv2.0.0がリリースされました。 v1.17からの変更点は上記リンクに書かれているとおりですが、日本語での情報が見当たらなかったので、ここで紹介しておきます。 Ruby 2.3以上、RubyGems 2.5以上が必須に Ruby 2.2系のサポートは2018年3月で終了しました。それに伴って新しいBundlerでもサポートされません。 Bundler 2.0.0ではRubyGems 3.0以上が必須とされていましたが、インストール時に問題が多発したようで、翌日にリリースされた2.0.1でRubyGems 2.5に戻されました。 Githubからのインストール時にhttpsがデフォルトに
!! 2024年1月版をhsbtさんが書いています !! 2020年12月版をhsbtさんが書いています !! 2020年2月版をhsbtさんが書いています !! 最新のVisual Studioでは後述のVisual C++の個別のコンポーネントで必要なものが異なるようです。よくわからない場合はそれっぽいものに片っ端からチェックをつけてみましょう 序 普通はRubyInstallerを使うんで、あえて茨の道を行きたい人向けです。以下の記事のアップデート版 https://qiita.com/nurse/items/6334a88bd446c177b6bd https://naruse.hateblo.jp/entry/2017/06/12/143220 ruby-mswinとは Microsoft Visual C++を用いて作成されるCRubyです。これはmingw版やcygwin版な
matsumoto-rさんのngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoCを参考に、Let's EncryptからSSL証明書を自動取得する仕組みを内包した nginx-fastcertificate を実現するDockerコンテナとdocker-compose設定例を作ってみました。 全体像 使い方 以下のような yaml ファイルを用意します。 version: '3' services: nginx: image: quay.io/akiray03/nginx-fastcertificate ports: - '80:80' - '443:443' volumes: - ./logs:/usr/local/nginx/logs links: - redis:redis environment: NGINX_WO
よくあるお問い合わせフォームみたいので、ユーザーの入力を一度確認画面みたいな感じで表示してから送信したい時・・ ユーザーが問い合わせの入力 「確認」ボタンをクリック 入力した項目を一度確認画面に表示(入力とほとんど一緒) 「送信」ボタンをクリック 実際にモデルとして保存 という流れをRailsで実装する時の定石 Model Question validates :title, presence: true validates :name, presence: true validates :content, presence: true validates_acceptance_of :confirming after_validation :check_confirming def check_confirming errors.delete(:confirming) self.conf
最終鬼畜FizzBuzz大全 - Qiitaに刺激を受けて、Qiitaのほうにポストしてみたんだけど、こちらは解説付きで。 Ruby的FizzBuzz - その1 class FB def FizzBuzz(n) (n%15)==0 end def Fizz(n) (n%3)==0 end def Buzz(n) (n%5)==0 end def self.call(n) instance_methods(false).detect { |m| new.send(m, n) } || n end end (1..100).each { |i| printf "%s ", FB.call(i) } # >> 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz 16 17 Fizz 19 Buzz Fizz 22 23 Fizz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く