「フロントエンド開発者」の終焉 | POSTD
元記事の著者より：この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます（答えは相手によって変わることもあります）。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLやCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPやMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです（これに関しては、後に詳しく説明します）。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな
Unixコマンド”yes”についてのちょっとした話 | POSTD
知っているUnixのコマンドで一番シンプルなものは何ですか？ 例えば echo という、stdoutに文字列を出力し true を返す – すなわち常に0の終了コードで終了するシンプルなコマンドがあります。 シンプルな、と言えば yes もそうでしょう。引数なしで実行すると、改行されたyが無限に出力され続けます。
コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD
私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。本記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える！」的な投稿ではありません。本記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注：私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、本記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報：本記事が r/p
Dockerの本番運用 | POSTD
以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項：対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈：書
#/usr/binとその同種の周辺を探る | POSTD
(注：2017/04/10、いただいたフィードバックを元に翻訳を修正いたしました。) はじめに 私はLinuxが大好きです。コンピュータとのやりとりが楽しくなるし学ぶことも多くなります。OSとハードウェアの基盤となる基本原則を学びたい人にとって、Linuxはとてもいい出発点と言えるでしょう。 ご存じのとおりLinuxとは大抵の場合プログラム（コマンド）を通してやりとりします。Linuxと他のUNIX系システムが持っている特徴は、コマンドラインと、パイプのコンセプトです。プログラムの提供する入力と出力を統合すれば、データを操作するのに非常にパワフルなプラットフォームになります。 Linuxのコマンド、プログラム、バイナリ（何と呼んでもいいのですが）の大部分は、/usr/bin、/usr/sbin/、/binそして/usr/local/binに存在しています。これらのディレクトリを見れば、プロ
JVMはそんなに重くない | POSTD
Clojureに反対する大きな理由がJVMです。この役立たずは重いですからね。 これは、数週間前に ZA Tech のSlackで見た投稿です。休暇中にClojureの話題を何件か見たのですが、投稿者はJVMについても繰り返し言及していました。 私はこの投稿について Slack上で少しつぶやいていました が、もっと広く理解され議論されるように、本稿を書くことを決めました。 背景 以前は、私もJVMは重いと思っていました。2000年代の初めにJVMとPHPと比べていた頃の話です。当時は、.NETやColdFusionなど、別の重い製品が他にもありました。また、PerlやPythonという軽めの製品もありましたが、私はWindowsを使っていたのでActivePerlやActivePythonはやはり少し重めでした。 私が初めてJVMに対する“恐れ”を克服したのは、小規模な製品アプリを、JRu
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
Capybaraを使って、Rails+JavaScriptの非同期な統合テストを書く | POSTD
上からも分かるように、ページの読み込みが完了する前に、テストでリンク探しを始めたのにも関わらず、Capybaraは優雅にインタラクションを処理しています。 しかし、Capybaraがこれらの非同期の問題を処理してくれるにもかかわらず、成功したり失敗したりする一貫性のないテストにいとも簡単に陥ってしまうのはなぜなのでしょう。 競合状態の数を最小限に抑えて、Capybara APIを正しく使用するには、いくつかのコツがあります。 最初に適合するエレメントを見つける 悪い例 first(".active").click まだページに.active要素がない場合、firstはnilを返し、クリックは失敗します。 良い例 # 完全に一致するものが欲しい場合 find(".active").click # ただ単に最初の要素がほしいだけの場合 find(".active", match: :first
人間らしいGitのエイリアス | POSTD
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD
本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ
Railsの基本理念 : Railsの生みの親が掲げる8つの原則 | POSTD
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
Airbnbのメインデータベースをどうやって2週間で分割したか | POSTD
スケーリング＝時速160㎞で走行しながら自動車の全ての部品を取り替えること －Mike Krieger Instagramの共同設立者＠ Airbnb OpenAir 2015 Airbnbのピーク時のアクセス数は、毎年夏のピーク時で見ると年率3.5倍で増加しています。 2015年夏の旅行シーズンを前に、Airbnbの基盤チームは、夏季のアクセスで予想されるデータ通信量に対処するため、データベースのスケーリングで忙殺されていました。中でも特に全体への影響が大きかったプロジェクトが、特定のテーブルを、アプリケーションの機能に従ってそれぞれのデータベースに分割することを目的としたプロジェクトでした。これは通常、アプリケーション層のフォームの変更やデータ移行、データの整合性を保証する堅牢性テストなど、最小限のダウンタイムで多大な技術的投資を必要とするものです。何週間もかかるエンジニアリング時間
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
JavaScriptフレームワークの寿命 | POSTD
(注記：9/13、いただいた翻訳フィードバックを元に記事を修正いたしました。) 半年ごとに”今一番ホットな”フレームワークが新たに登場しては、私たちは興奮に沸き返ります。 誇大広告を信じてはいけません。 フレームワークの寿命 はプロジェクトの成功を左右するほど重要な要素です。フレームワークを選ぶ際、テクノロジにおける多くの意思決定者は納得のいく選択をするために、コミュニティの大きさ、人気、大企業によるサポートの有無などを基準にしています。しかし実際は、こうした要素によって寿命が決まるわけではありません。 最初は勢いがあったのに、徐々に弱まり、最終的には線香花火のごとく儚く消えてしまうようなフレームワークを選んでしまうと、書き直しに無駄な時間を費やしたり、チームの士気を下げたりする原因となります。本記事は、そうした残念な結果を回避するヒントをまとめたものです。 本記事では以下のことを示したい
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
Atomの重要なプリミティブの最適化 | POSTD
これまで数カ月にわたり、私たちはAtomのパフォーマンスの改善に取り組んできました。その結果、最適化するための課題として特に興味深いのが マーカ という構造体だと分かりました。マーカはバッファの内容が変更されても、バッファの論理的な領域を追跡することができます。例えば、以下の図で緑色のハイライトがかかった部分のマーカは、文字列を書き換えたとしても同じ領域に残り続けます。 マーカは、Atomの機能を幅広くサポートする基本的なプリミティブです。検索および置換を行う場合には、マーカを使うことで 検索結果のハイライト表示 ができます。スニペットの場合も、文字列を書き換える際にマーカを使い、 タブストップで移動する位置 を追跡することができます。さらにはスペルチェックの場合でも、マーカを使って スペルミスのある単語を抽出 したり、その単語を書き換える際の再チェックをしたりすることもできます。そもそも
プログラマ能力指標表 | POSTD
2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造
モノリシックなRubyからGoによるマイクロサービスへ | POSTD
過去9年わたりWebアプリケーションを開発してきたNiket氏（ @nexneo ）は、2013年からGoを使って作業をするようになりました。この講演では、彼がどのようにRubyのモノリシックアプリケーションを分解しつつ、Goで記述されたマイクロサービスへと至ったかについて説明しています。講演のスライドは、 speakerdeck.com/nexneo/joy-of-single-purpose-services-in-go で閲覧可能です。 Single purpose servicesというのは、単一の問題を解決するサービスのことです。 一般的に マイクロサービス としても知られています。 Niket氏は、学校側が親御さんたちと連絡したり成績表や出席を管理したりするための人気オンラインプラットフォーム、 Beehively の開発者です。BeehivelyはRubyベースのアプリケーシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
