タグ

postdに関するyutaszk23のブックマーク (9)

  • 「フロントエンド開発者」の終焉 | POSTD

    元記事の著者より:この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます(答えは相手によって変わることもあります)。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです(これに関しては、後に詳しく説明します)。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな

    「フロントエンド開発者」の終焉 | POSTD
  • 分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD

    分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア (それがどういう意味であれ)になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped

    分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
  • くだらないAPIなんていらないよ – 2016年のウェブスクレイピング事情 | POSTD

    ソーシャルメディアのAPIとそのレート制限は、あまり気分のよいものではありません。特にInstagram。あんな制限つきAPIを欲しがる人がいったいどこにいるんでしょうね? 最近のサイトは、スクレイピングやデータマイニングの試みを阻止するのがうまくなってきました。AngelListはPhantomJSすら検出してしまいます(今のところ、他のサイトでそこまでの例は見ていません)。でも、ブラウザ経由での正確なアクションを自動化できたとしたら、サイト側はそれをブロックできるでしょうか? 並行性を考えたり、さんざん苦労して用意した結果として得られるものを考えたりすると、Seleniumなんて最悪です。あれは、私たちが「スクレイピング」と聞いて思い浮かべるようなことをするためには作られていません。しかし、賢く作り込まれた今どきのサイトを相手にして、インターネットからデータを掘り当てるための信頼できる

    くだらないAPIなんていらないよ – 2016年のウェブスクレイピング事情 | POSTD
  • WebSocket大合戦:Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD

    Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。

    WebSocket大合戦:Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD
  • 生のReactを知ろう – JSX、Flux、ES6、Webpackを使わず… | POSTD

    (編注:2016/07/29、いただいたフィードバックをもとに記事を修正いたしました。) 免責事項: 私はJSX、Flux、 ES6 、そして webpack を非常に気に入っています。これらのツールについては他のシリーズで話します。 React.jsが騒ぎを起こしているのはご存知の通りです。確かに、 XMLHttpRequest 以来の良いツールです。しかし、調査に数時間を費やした挙句、あまりに多くの用語に 圧倒された だけで終わっていないでしょうか。JSX、flux、ES6、webpackreact-routerが使える今、 *他に必要なのは React の使い方を説明してくれる人だけです。* 喜んでください、それがまさに当シリーズでやろうとしていることです。信じられませんか?大丈夫、 2分後、 初めてのReactアプリを作った後には納得いただけるでしょう。何もダウンロードせずに、で

    生のReactを知ろう – JSX、Flux、ES6、Webpackを使わず… | POSTD
  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
  • DHHはどのようにRailsのコントローラを書くのか | POSTD

    私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

    DHHはどのようにRailsのコントローラを書くのか | POSTD
  • あなたは全部知っていますか?プログラミングの業界用語30選 | POSTD

    Stack Overflowは、私が学習に役立ててきた多くのオンライン・コミュニティと同じように、自然と厳しくなってきました。第一にこれは、自己防衛機能です。子どもが初めて学校や託児所に入ると広大な世界にさらされて、 髄膜炎菌症を発症 して日々くしゃみやせきを繰り返しながら成長するのと同じような免疫システムです。常に好ましいことだとは言い難いですが、生き残るためには必要なプロセスなのです。 2年前に投稿された、下記の質問のことを考えてみてください。 あなたが新しく作ったプログラミングの業界用語は何ですか? あなたが作り、あなたの周りで使われるようになった、プログラミングの用語は何ですか?(他の人が真似して使っているのを聞いた、など)あなた独自の言い方が、職場内でのみ使われていたり、インターネット上で幅広く普及していたりすることもあるでしょう。 独自のプログラミングの用語、単語、言い回しを太

    あなたは全部知っていますか?プログラミングの業界用語30選 | POSTD
  • ある中級プログラマの告白 | POSTD

    私は中級レベルのプログラマです。 基を理解するのは得意です。過去の失敗をきちんと分析できるくらい経験を重ねていますし、もっと知るべきことは山ほどあることも分かっています。 特筆すべきは、自分で身につけるべきことを知ったうえで、それを吸収しようと積極的かつ精力的に取り組んでいる点でしょう。 プログラマとしての能力は平均的なものに過ぎないと、心から納得するまで時間がかかりました。今では、よく理解できないままに誰かの意見を受け売りする必要など感じていません。知らないことがあっても、それを他人に悟られるのは怖くありません。 でも以前は違いました。信じられないかもしれませんが、私はかつてプログラミングの達人だったのです。 自分の能力を誤って評価していたのは、比較的孤独な環境でスキルを学んだためでしょう。当時はコンピュータを持っていることさえ、ちょっと特別なことでした。使い方を知っているとなれば、な

    ある中級プログラマの告白 | POSTD
  • 1