Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここでプログラミング言語Rubyの生みの親であるまつもとゆきひろ氏が登壇。まずは、「成功するソフトウェア」における「成功」について話します。 Rubyは30年間生き延びたソフトウェアプロダクトまつもとゆきひろ氏（以下、まつもと）：それでは発表をさせてください。「成功するソフトウェアの作り方」と題しまして、Rubyのまつもとが発表します。先ほど「Heroku」の発表がありましたが、私は元Herokuなので、すごく懐かしく聞いていました（笑）。 （スライドを示して）こんなアイコンでふだん活動しています。 英語圏ではMatzという名前を使っています。Rubyを作った人として知られて
新しくプロダクト開発を始める時、あなたはどの言語でコードを書くことを選ぶでしょうか？ シンプルに、スピーディーに開発が行える言語？メモリ効率や実行速度に優れた言語？はたまた一生使い続けると愛を誓った言語でしょうか。 今回は、そんな言語選定における選択肢としてのDSL(ドメイン固有言語)とその作り方について、Rubyを用いたコードを通して紹介していきます。 大和 拓朗（おおわ たくろう） 株式会社メンバーズ メンバーズエッジカンパニー Webエンジニア 2018年中途入社。SNS分野でのフィード広告運用システム・キャンペーン管理システムの開発に従事。 最近のブームは、リモートワーク定着を口実にしたホームオフィス環境の整備やスマートホーム化。お寿司とドーナツが好き。 GPLとDSL 言語選定は、プロダクトに求められる要件（保守性やパフォーマンス、セキュリティなど）を基準に、言語自体の性質、業界
はじめに テストダブル（Test Double）について、わかりやすく解説した技術記事はないかな〜と探していたところ、こちらのブログ記事を見つけました。 goyoki.hatenablog.com とても詳しく解説されていたので、まさに打ってつけだったのですが、ふだん僕はRubyを使っているのでサンプルコードをRubyにしてみたいな〜と思いました。 そこで今回のエントリでは、原著者の id:goyoki さんの許諾をいただいた上で、上記のブログ記事の説明文を維持したまま、サンプルコードだけをRubyに書き直してみました。（goyokiさん、どうもありがとうございます！） ただし、Ruby版のコードにあわせて説明文を改変した箇所もいくつかあります。 それでは以下がRuby版の「xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の
こんにちは、Webチームの柴山（@shikeapp0909）です。 今回は、弊社Webアプリ「mamanoko」の一部に処理高速化のためにGoを導入したので、どのように導入したかをご紹介しようと思います。 Railsで開発しているWebアプリ内にどのようにGoを取り入れたのか、実際のコード例を交えながら解説していきたいと思います。 なぜRails環境にGoを導入したのか そもそもなぜGoを導入することになったのかと疑問に思われるかと思います。 mamanokoはメディアサービスのため、ライターさんに文章を書いていただいています。複数のライターさんがおり、文章量も膨大になるため、表記揺れや誤字がどうしても出てきてしまいます。 そのため、文章校正が必要であり、以前からその機能を提供していました。 しかしこの文章校正の機能は記事の文章に対して表記揺れなどチェックしたい単語を総なめする処理をしてい
こんにちは！ SmartHRエンジニアの @tei-k です。 SmartHR ではインフラに AWS の Elastic Beanstalk (以降 EB ) を使っています。 Rails アプリですので、去年までは Ruby Platform 上で動いたのですが、今年から Docker Platform へ切り替えました。 ここでは移行するまでの工夫をご紹介できればと思います。 EB の概要 EB は、インフラストラクチャーを意識せず簡単にアプリケーションの構築、デプロイ、Auto Scaling などをマネジードしてくれる PaaS となります。 Ruby、Go など様々な言語や Docker にも対応しているため、すべての言語のアプリを EB 上で動かせるでしょう！ 詳細は公式ドキュメントご参考下さい。 移行の背景 Ruby Platform には以下の制限や要望がありました。 最
リサーチ・アンド・イノベーションの浜田(hamadu)と申します。 いつものお買い物がちょっとお得に、家計簿にもなるポイントアプリ「CODE」のサーバサイド、およびAndroidアプリの開発を担当しています。 序 CODE ではバックグラウンドジョブシステムとして、Sidekiq を採用しています。その作者、Mike Perham 氏が新しい仕組みを作っていました。その名も Faktory。Sidekiq と違いワーカーが言語に依存せず、また本体はGoで書かれているためスケールするのがウリのようです。まだまだ開発中で、プロダクションで使うには厳しい印象を受けますが、今後Sidekiqを置き換えうるプロジェクトになるのではと思います。 本稿では簡単に仕組みの紹介をして、Rubyでジョブを投げるClientと、ジョブを処理するワーカーをそれぞれ実装してみました。 ソースコードは faktory
モバイルアプリサービス部の五十嵐です。 先日、あるRailsアプリケーションの開発環境を同僚のマシンに作成しようとしたところ、gemのインストールに1日かかってしまいました。環境構築は手順化されていたのですが、トラブったのは主にNative Moduleを利用する libv8 、 therubyracer 、 rmagick などのおなじみの面々です。手順を作った時は、これらのgemのインストールに必要なライブラリを brew install で最新バージョンをインストールするだけでよかったのですが、時が経ちライブラリの最新バージョンが更新されていたことが主な原因でした。この状況はいかんな〜と思い、Railsアプリケーションの開発環境もDockerにすることにしました。 本記事では、Railsアプリケーションの開発環境をDockerにするときに検討したことや問題点などを書いています。なお、
【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略 - connpassに参加してきました。若手エンジニアないしはエンジニアを目指す学生向けに、生存戦略を説く主旨の講演でした。まつもとゆきひろ氏とは、プログラミング言語・Rubyを作った人です。 全体的な内容はこちらのブログで非常にコンパクトに紹介されているのでご参照ください。 zuckey17.hatenablog.com 私のブログではまつもとゆきひろ氏もといMatz氏が語ったことを前半に紹介しつつ、後半に主観感想もまとめたいと思います。 ■生き残るには？ -死ななければいい。 「エンジニアの生存戦略、つまり生き残るには？」 その問いに「単純ながら、死ななければいい。」という皮切りでスタートした。 じゃあこの"死なない"ためにはどうするか。 そもそも生き残るとはどのような戦略を取ればいいのか？ Matz氏は「背景や環境など当然違う
ども、@kimihom です。 私は Heroku に Rails サーバーを立ててサービスを運用している。これまでの経験を元に、定期的にチェックしておきたい指標とか項目をまとめてみる。今後のサービス開発などで参考になれば幸いだ。 サービス構成 現在の構成はというと、以下のような感じである。 Ruby 2.4.1 (執筆時点で最新) Ruby on Rails 4.2.8 Heroku Standard 1X Dyno * 4 Heroku Postgres Standard 0 Heroku Redis Premium 0 もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予
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 5.1: Loving JavaScript, System Tests, Encrypted Secrets, and more In celebration of the 12th RailsConf in Phoenix, Arizona this week, we’re proud to announce that Rails 5.1 is ready in its final form! We’ve spent over 4,100 commits since Rails 5.0 making everything EASIER, SIMPLER, and, uhhh, FUNNER? (That’s a RailsConf joke). The highlight reel hasn’t really changed since the first beta, bu
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
この記事は feedforce Advent Calendar 2016 - Adventar の2日目の記事です。 1日目は 源義経のシンプルな考え方が好き - Marketing book でした。良い話だ。(ちなみに大河ドラマが平清盛だった年は、我が家では後白河院の評価が高かったです。懐かしい。) RubyCriticのご紹介 rubyエンジニアなのでrubyのことを書きます。 RubyCriticはrubyコードを静的解析するツールです。rubygemで提供されています。 単純な使い方としては、$ gem install rubycritic するなりbundler使うなりしてインストールし、 $ rubycritic . を実行します。$ rubycritic ./app ./lib のように、指定のディレクトリだけを対象にして実行することもできます。 実行すると./tmp/ru
うーん、structural subtypingとダックタイピングは同じものなんだろうか。— Yukihiro Matsumoto (@yukihiro_matz) 2016年9月8日 https://t.co/5Rv86piThC wikipediaによると似て非なる物のようですね。 https://t.co/VwIg39h5M0— INADA Naoki (@methane) 2016年9月8日 この話題について補足しておきます。なお、僕はTAPL脱落組なのであまり正確性は期待しないでください。 背景 Ruby Kaigi で Matz が Ruby3 に向けて考え中の静的型について話されたようです。 少し前から、 Python でも Guido が Dropbox での大量のコードベースを改善していくために type hinting がほしいということで PEP 484 を始めました
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 現在、TensorFlow、Chainer他多数のDeepLearning用ライブラリが公開されています。 本格的なアプリケーションで使うには実行スピード、クオリティ、拡張性、ドキュメント、コミュニティの充実等多くの面で、それらの中から選択して使用するのが鉄板な状況です。もちろん、私もメインではそれらを使わせてもらっています。これらのライブラリ、例えばtensorFlowではcomputatoin graphを構築、operationを追加してそれを実行というイメージで（行列、数式で取り扱うイメージ）、根底にある古典的なニューロン
世界初のプログラム内蔵方式コンピュータに搭載された、最初のプログラムを書くのに使われた言語は何だったでしょうか？ もちろん、バイナリの機械語です。 なぜですか？ えー、当然ながら、シンボリックアセンブラがなかったからです。最初期のプログラムは、バイナリで書かなければなりませんでした。 バイナリの機械語と比較して、アセンブリ言語でプログラムを書くと、どのくらい簡単ですか？ ずっと 簡単です。 数字を言ってください。何倍ぐらい簡単ですか？ えー、まあ、アセンブラは、あなたの代わりに面倒な事務処理を全てしてくれますからね。つまり、全ての物理アドレスの計算です。全ての物理的な命令を構築するわけです。あなたが範囲外にアドレス指定するなど、物理的に不可能なことをしないよう確認します。そして、簡単にロードできるバイナリの出力を生成します。 それによって、軽減されたワークロードは、 膨大 です。 どのくら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
