プルリクエストをより使いこなす | POSTD
Gitを使用している人であれば、プルリクエストには馴染みがあるでしょう。これは、分散バージョン管理システムが世に出始めてから、何らかの形で使われています。BitbucketやGitHubのように凝ったWebユーザインターフェイスが構築される前は、プルリクエストは単純に電子メールベースで行われており、Aliceのリポジトリから変更をプルするように依頼していました。プルリクエストを受けた側がこの変更を妥当だと判断すれば、いくつかのコマンドを実行しmasterブランチに変更をプルするという流れです。 $ git remote add alice git://bitbucket.org/alice/bleak.git $ git checkout master $ git pull alice master もちろん、手あたり次第Aliceの変更をmasterにプルすることは、 得策 ではありませ
JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
@extendを使うべき時、@mixinを使うべき時 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) 私がクライアントからよく受ける質問に 「@mixinと@extend、それぞれどのような時に使うべき？」 というものがあります。 “引数を使わない@mixinは悪である”。 これは以前からある経験則です。同じコードを2つのインスタンスで重複させるだけの@mixinは不快でさえあります。しかし、@extendを使うべき時、@mixinを使うべき時、これらを見極めることにはもっと深い意味があるのです。 それでは詳しく考察していくことにしましょう。 私は普段、@extendは決して使わないようにとアドバイスしています。@extendには、一見したところ魅力的な特徴がたくさんあるのですが、注意しなければいけない点はそれ以上にあります。言ってしまえば 見かけ倒し だということです。 それでも@extendを使い
モノリシックな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ベースのアプリケーシ
【翻訳】AngularJSからReactへ: Isomorphicな方法 | POSTD
先週、私たちはWebサイトを検索エンジン向けにインデックス付けできるようにしようとしていました。この記事では、私たちがWebサイトを書き直していて学んだことの要約を紹介したいと思います。 背景 2ヵ月前に RisingStack.com を作成した時、私たちはそのWebサイトでどんなテクノロジを使うか決めなくてはなりませんでした。イベントを追跡する静的なページが数ページあるだけだったので、とても簡単でしたが、私たちはWebサイトをスケーラブルでできるだけ高速なままにしておきたいと考えていました。 私たちのチームは AngularJS の経験が豊富なので、フロントエンドにAngularを選ぶのは妥当だと思われました。 この記事はReactやAngularJSがどちらか一方より優れている理由について述べているわけではないので注意してください。どちらがいいかは常にユースケース次第です。 “Ang
Makeについて知っておくべき7つのこと | POSTD
Make は、様々なタイプのファイルのビルド作業を自動的に行ってくれるシンプルかつ強力なツールです。しかしながら、makefileを書く際に問題にぶち当たるプログラマもいれば、Makeの基本知識がないことで、既存のものを再発明してしまうプログラマもいます。 Makeの働き デフォルトでは、Makeは一番目のターゲットから開始します。このターゲットのことをデフォルトゴールと呼びます。 Makeはカレントディレクトリのmakefileを読み込み、一番初めのルールで処理を開始します。しかし、Makeが完全にこのルールを処理する前に、ルールが依存するファイルのためのルールを処理しなければなりません。各ファイルそれぞれは、自身のルールに従って処理されます。 実はこれは、各ターゲットの再帰的アルゴリズムになっています。 ターゲットをビルドするルールを見つける。ルールがないようであれば、Makeはうまく
Gitコマンドラインショートカット | POSTD
私は多くの時間をターミナルの前で過ごしていて、そのほとんどをGitコマンドのタイピングに費やしています。ワークフローを高速化して、毎日何百というキーストロークを節約するために、Bashのエイリアスと関数を使って1組のコマンドラインショートカットを作りました。 Git Bashエイリアスと関数 Gitではエイリアスを設定できますが限定的であり、節約できるキーストロークは、ほんの数ストロークです（例えば、”git checkout”の代わりに”git co”とタイプすることはできますが、まだ”git”とタイプしなければなりません）。Bashはターミナルのデフォルトのコマンドラインインタープリタなので、Bashエイリアスを設定して、さらにキーストロークを減らすこともできます。 これが、私のGit Bashエイリアスと関数のリストです。ご自分のエイリアスや関数の保存先ファイル（例えば、~/.bas
Goを使い複雑性を回避する | POSTD
『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』 を書いたFred Brooksはその論文の中で、 偶有的な複雑性と本質的な複雑性 について重要な区別をしています。 本質的な複雑性 とは、問題特有の領域から生じる複雑性のことを指します。例えば、SMTPクライアントを作成しているディベロッパは、 RFC 5321 の核心の細かいところ全てに取り組む必要がありますが、これはSMTPクライアントの作業をする上で避けては通れないものです。これに対して 偶有的な複雑性 とは、私たちが自ら作り上げた問題から生じる複雑性のことを指します。 技術者としては、自らの選択で生じる偶有的な複雑性によって、余計な負担が増えないようにとても注意しなければなりませんよね。その意味では、言語の選択は偶有的な複雑性を軽減できる完璧な例と言えます。Webアプリケーションを書くのにアセンブリ言語を選びます
さあGoを始めよう！環境構築，”Hello World”から簡単なバックエンドサーバーまで | POSTD
Goは、 信頼できる賢い人たち によって作られた愛すべきささやかなプログラミング言語で、 現在も成長中の大規模なオープンソースコミュニティ によって、継続的に改善が続けられています。 Goの基本原則はシンプルであることですが、時折、約束事が分かりにくいこともありますね。以下では、私がどのようにしてGoのプロジェクトを始め、どのようにGoのイディオムを使っているかを紹介したいと思います。一緒に、Webアプリケーション用のバックエンドサービスを構築しましょう。 環境の構築 新規プロジェクト Webサーバの作成 ルートの追加 複数APIへのクエリ 並列化 シンプルさ 追加演習 環境の構築 最初のステップは、もちろんGoをインストールすることです。オフィシャルサイトに用意されている、 お使いのオペレーティングシステム用のバイナリディストリビューション を使ってください。MacでHomebrewを使
ポール・グレアムによる「経験することと自覚について」 | POSTD
私はVillehardouinが書いた第4次十字軍の年代記を少なくとも2回、多分3回読みました。それにもかかわらず、覚えている内容を全部書いてみろと言われたら、1ページくらいしか書けなそうです。このようなことが増えてきて、私は自分の本棚を見て不安な気持ちになります。内容をほとんど覚えていないなら、これらの本を全部読んだところで一体何の役に立つのでしょうか？ 2、3か月前、Constance Reidが書いたHilbertの優れた伝記を読んでいた私は、この問いに対する答えを見つけたわけではないのですが、少なくとも気が楽になりました。彼女はこう書いています。 Hilbertは、学生たちに事実を詰め込むような数学の講義に我慢ならず、問題の定式化の方法や解き方を教えませんでした。彼は学生たちに「問題の最適な定式化を行うことは、その問題の半分を解いたも同然だ」とよく話したものです。 私にとってこれは
ポール・グレアムによる「意地の悪い人は失敗する」 | POSTD
最近私は、自分が知る成功者の中には意地の悪い人がほとんどいないということに気がつきました。例外はありますが、ごく少数と言っていいでしょう。 意地の悪い人というのは、決して珍しい存在ではありません。事実、インターネットの世界では、人がどれだけ意地悪くなれるかということを簡単に目にすることができます。自分の意見を公にすることは、数十年前までは有名人やプロの作家でもなければできないことでした。それが誰にでもできることとなった現在、これまで隠れていたような意地の悪さまでもが、簡単に私たちの目の前に現れてしまうようになったのです。 意地の悪い人は世の中にたくさん存在しているにもかかわらず、なぜか私が知る成功者の中にはほとんど見当たりません。これは一体なぜなのでしょう？ 意地の悪さと成功には、反比例の関係があるのでしょうか。 もちろん、どの分野でもそうだと言っているわけではありません。私がよく知ってい
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
Y combinatorのサム・アルトマンによる『ボードメンバー』 | POSTD
この5年ほどの間に、影響力の行使において、投資家から創設者への劇的なシフトが見られるようになりました。これは概ね歓迎すべきことですが、いくつかの重要な側面においては、悪影響を及ぼしています。主導権を握りたいという創設者の思いが適度に保たれているうちは問題ありませんが、それが行き過ぎると会社に損害を与えることになります。 多くの創設者（少なくとも私がこれまで話したことのある創設者の多く）は、一般的に社外取締役を迎えることには消極的です。現状では、投資家に対して取締役(ボードメンバー)のオファーを出さないことが、シリーズAを勝ち取るためには都合のいい方法です。投資家の中にはそのことを歓迎する人たちもいます。取締役になるよりも、小切手を切った後はビーチでのんびり過ごす方が楽に決まっていますからね。この流れはしばらく続きそうです。というのも、このような新しいタイプの投資家は、会社の意思決定に関与し
Haskellを愛する若者たちへ | POSTD
この手紙は、”熟練者”ならではの知識を語るものではありません。新人かベテランかに関わらず、私たちの誰もが繰り返し学び、覚えておくべきことについて書いています。ここでは、一般的な傾向や、聞けばなるほどと思うような傾向、重要とされていることを新たに学んで興奮している時に見られる傾向を紹介します。また、学んだことの面白さや重要性を人にきちんと伝わるように話すことの難しさについてもお伝えします。この手紙はかなり具体的に書いています。一般的な話をするなら具体的なことも併せて話さなければ理解してもらえないと悟ったからです。これは代数的構造やその他の抽象的な概念についても言えることですね。この手紙には、私が頭に入れておきたい、また皆さんに共有したいアドバイスが詰まっています。インターネット上で適切とは言えない振る舞いをしている人に出くわした時、そんなことはめったにないでしょうが、そんな時に思い出したい内
MediumのCSSはこの上なく最高！ | POSTD
自分は常に最高であれって思っている。最高の香りを身にまとい、最高の振る舞いをする。ごみ1つ捨てるのだって、ほかの誰よりイカしてなきゃ。 ―Lil Wayne ずっと長いこと恥も外聞も知らずに、MediumでCSSについて執筆しようと思っていました…。 それからどうなったって？ 違うことをやっていた？ 何てこと、どうやったら同じことができるかって？ やり方を教わりたいって？ これから書くことは私たちのCSSについての覚書で、これまでに歩んできた道のりと現在のCSSについて述べています。 始まり（これまでの道のり） だいたい2年ほど前、私はソフトウェアアプリケーション開発と（皆さんが読んでくれているといいのですが） medium.com に取り組むためにObvious Corp.に加わりました。 その時、Mediumは、すでに一連の”スタイル更新”を行っていました（ スタイル更新とは デザイナ
Haskell製サービスを本番投入 | POSTD
thoughtbotはWebとモバイルアプリを開発するWebコンサルティング会社。Railsの有名プラグインであるPaperclipやFactory Girlなどのオープンソースプロジェクトや、自社プロダクト（hound、Upcase）も開発している。ボストンをベースに、サンフランシスコ、デンバー、ニューヨーク、フィラデルフィア、ローリー、ストックホルムにオフィスを持っている。 数週間前、私たちはGiant Robotブログで新しいコメント機能をひそかにリリースしました。パラグラフやコードブロック上でホバーすると、右側に小さなアイコンが表示され、その記事の該当するセクションにコメントできる機能です。 この機能を公開して、これまでずっと言いたかったことがようやく言えます。ついにHaskellのサービスを一般出荷しました！ ここでは、リリースの概要および仕組みを説明し、私たちが遭遇したさまざま
爆速HTML – Elmでの仮想DOM | POSTD
新たな elm-html ライブラリでは、HTMLとCSSをElmで直接使用できます。FlexBoxも使ってみたいし、既存のスタイルシートも使い続けたいですか？ Elmは使いやすくなり、処理が 速く なりました。例えば、 TodoMVC アプリを再作成する場合、Elmの コード はとても単純で、 事前のベンチマーク でも、他の人気ライブラリに比べ処理速度が極端に速いという結果が出ています。 elm-html とMercuryは、どちらも virtual-dom プロジェクトを基にしているので、パフォーマンスが優れています。この記事では、前半で“仮想DOM”とは何か、 純粋性 と 不変性 によっていかに処理速度が上がるかということについて詳しく検証します。この検証によって、なぜOm、Mercury、Elmがベンチマークでこのような素晴らしい数字を出したかが分かるでしょう。 パフォーマンスは人
抽象化と組み合わせができるレイアウト言語があれば、CSSは必要ない | POSTD
Web上の視覚的なスタイルを指定するCSSは、あまりにも複雑で、恐らく今までに一度も正確に実装されたことはないだろう。それにもかかわらず、バージョンが上がるにつれて、その複雑さは増すばかりだ。一方で、CSSではできることが限られており、初歩的なデザインでさえ不可能であるか、あるいは法外に難しいことも少なくない。加えて状況依存的（または計算的）な側面を持つものは、すべて外部で対応しなければならないという有様だ。その結果、CSSに関するほとんどの手引きでは、希望する外観に何とか近づけたり、非互換性を回避したりするための頼りないハックに多くの労力が費やされている。 – Bret Victor 私は近年、クライアントサイドの開発技術を数多く見てきました。そして、その中でも特に興味深いと思ったのが Elm です。関数型のプログラミング言語としては、Elmはそれほどワクワクするようなものではありません
フロントエンドのプログラミング言語をゼロから設計した理由 | POSTD
本エントリは 翻訳リクエスト より投稿いただきました。 ありがとうございます！リクエストまだまだお待ちしております！ 現在、私たちが使っているプログラミング言語の数々は、技術分野の巨人たちが時代の流れと共に生み出してきたもので、それぞれが膨大なコードで構成されています。そのため、仮に何らかの修正が必要となった場合、設計者たちは、問題に関係のある箇所のみを、差分的な形で随時マイナーアップデートするという形を採ってきました。C言語やJava、それにJavaScriptといった広く普及している言語において、その改革が遅々として進まないのは、このことに原因があるでしょう。 PythonやRubyといったオープンソースの言語は、バックエンドの問題を解決する手段として、スタートアップの現場で重宝され広く普及しましたが、言語設計者にとっては、レガシーコードの制約や言語関連の委員会による政治的なしがらみも
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
