タグ

ブックマーク / postd.cc (17)

  • Web 3.0: Webの移行が始まっている | POSTD

    多くの人が気付かないうちにWeb2.0からWeb3.0への移行が進みそうです。アプリケーションの見た目は現在使っているものとほとんど変わりませんが、バックエンドで変化が進んでいきます。未来を予測する人ならば、クラウドを使うSiacoin、ソーシャルメディアのプラットフォームとしてのSteemit、さらに未来を予想する手段としてAugurも頭に浮かぶのではないでしょうか。 適正に動く最初のブロックチェーンがリリースされたことを見れば、人々がWeb2.0を離れWeb3.0へ向かっているのは明らかでしょう。なぜなら、開発者というのはテクノロジーとWeb2.0のユーザーフレンドリーな手法を身につけても、更に使いやすいと考えられているWeb3.0に着手しようとするからです。 上の図の分布では、いろいろな企業とWeb2.0のセグメントが示され、ブロックチェーンに基づいたプロジェクトのどれに勝ち目がある

    Web 3.0: Webの移行が始まっている | POSTD
    yukatou
    yukatou 2019/01/25
  • ブロックチェ-ンを構築しながら学ぶ | POSTD

    ブロックチェ-ンの仕組みを知るには構築するのが最短の方法 この記事を読んでいるということは、仮想通貨の拡大に興奮しているということですね。ブロックチェ-ンの仕組み、背後にある基的なテクノロジーについて知りたいのでしょう。 しかしブロックチェ-ンを理解するのは簡単ではありません。少なくとも私にはそうでした。大量の動画の中をさまよい、抜けだらけのチュートリアルに従い、結局、実例が少なすぎてフラストレーションが大きくなりました。 私は手を動かして学ぶのが好きです。コードのレベルで内容を扱わざるを得なくなり、そうすることで身に付くからです。同じようにやってもらえば、この解説が終わる頃には、機能するブロックチェーンが出来上がり、どのように動くかがしっかりと把握できるようになるでしょう。 準備 ブロックチェ-ンとはブロックという名の 不変でシーケンシャルな 一連のレコードだということを覚えてください

    ブロックチェ-ンを構築しながら学ぶ | POSTD
    yukatou
    yukatou 2018/03/07
  • 2017年JavaScriptのテスト概論 | POSTD

    稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを

    2017年JavaScriptのテスト概論 | POSTD
  • DockerでのNodeアプリ構築で学んだこと | POSTD

    以下に紹介するのは、 Docker を使って node.js 用のWebアプリケーションを開発、およびデプロイする際に、私が四苦八苦しながら学んだ秘訣やコツです。 このチュートリアル記事では、Dockerで socket.ioのチャットサンプル を白紙の状態から番状態へとセットアップしていきます。このプロセスを通じて、そうした秘訣などを簡単に習得していただければ幸いです。特に、以下のような内容について見ていきます。 実際にDockerでNodeアプリケーションを起動する。 すべてをrootとして実行させない(悪いやり方です)。 開発時のテスト-編集-リロードサイクルを短くするため、バインドを使用する。 再構築を高速にするため、 node_modules をコンテナで管理する(これには秘訣があります)。 npm shrinkwrap で、ビルドを反復可能にする。 開発環境と番環境で Do

    DockerでのNodeアプリ構築で学んだこと | POSTD
  • モーションデザインはUIの未来 | POSTD

    最近、「モーションデザイン」という言葉がデザイン業界で急に出てきていることに気づいていますか?大小様々な企業が、これに特化した肩書きを持つデザイナーたちを雇いはじめています。最近ではGoogleが I/Oカンファレンス で、Googleの製品で統一化されているモーションランゲージの概要について話していました。 この騒ぎは何でしょうか?そして何の意味があるのでしょうか? モーションはストーリーを語ります。 アプリにおける全ての物事は連鎖になっていて、モーションはあなたのガイドになります。ボタンをクリックして、画面が変わる度に、そこにはストーリーがついてきます。例えば、アイテムを作ったり削除する時、アニメーションがどのように役に立つかを見ていきましょう。 アイテムを消すことは劇的で破壊的な作業ですので、適切に反応するようにしましょう。アイテムをただ画面から消すだけということはしないようにしまし

    モーションデザインはUIの未来 | POSTD
  • APIデザインにおける七つの大厄介 | POSTD

    (編注:2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか(私がしたことを見てください)。 リスティクル(箇条書き形式の記事) を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」

    APIデザインにおける七つの大厄介 | POSTD
  • 難しいことを簡単に学ぶ方法 ― 強力なスキルを新たに身に着けるための3つのステップ | POSTD

    ここ数年、私はWeb開発と機械学習の自習に多くの時間を割いてきました。 学習のテーマは、Javascript、Node、ReactからPython、scikit-learn、ニューラルネットワークに至るまで多岐にわたりましたが、全てに対して私は一貫したアプローチで取り組みました。 そのアプローチとは、単純な(陳腐と言ってもいい)3ステップで進める、という手法です。しかし、 Web開発のシロウトだった私が5カ月で、プロだと自覚できるほどになった のはひとえに、このアプローチで臨んだ自習の成果だと思っています。 そこで私は、この自習法がほかの誰かのお役に立てるかもしれないと思い、少し記事を書いてみることにしました。 この記事は、何も分からないままやみくもに挑戦を始めた、2012年当時の自分自身に教えるつもりで書いています。 ステップ1:習うより慣れろ 新しいテクノロジを学ぶためにまず実行する最

    難しいことを簡単に学ぶ方法 ― 強力なスキルを新たに身に着けるための3つのステップ | POSTD
    yukatou
    yukatou 2016/02/18
  • 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
  • 分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD

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

    分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
  • アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD

    注釈: CASH LAYER:キャッシュレイヤ FRONT END:フロントエンド ASSET SERVE:アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER:ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD:クラウド ALL READS! :全ての読み込み WRITES:書く READS:読む MASTER:マスタ INPORTANT POINTY THINGS:重要な鋭い情報 MULTI MASTER DB CLUSTER:複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

    アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
  • スレッド処理は慎重に – PHPでのスレッド処理 : 前編 | POSTD

    私が覚えている限り、非常に重い(または非同期の)タスク処理に関して、PHPは常に厳しい評価をされていました。これまではずっと、長いタスクを並列化したければ pcntl_fork を通してフォークするという方法を取らなければいけなかったので、タスクの結果を適切に処理することができませんでした。 そこで私たちは、キューイング(どちらかと言えばタスクを遅くするだけ)やReactPHP、または他の言語を一緒に使うといった、より複雑なソリューションへと向かっていきましたが、PHPでもスレッド処理は可能なのです。そしてより重要なのは、 その方法はあなたが思っているよりもはるかに簡単だということです。 この記事では、 pthreads 拡張(POSIX Threadsの略)について説明します。2012年ごろから広く使われていますが、多くの人がその存在を忘れているか、使うのが苦痛だと考えると思います。その

    スレッド処理は慎重に – PHPでのスレッド処理 : 前編 | POSTD
    yukatou
    yukatou 2015/12/24
  • より良いプログラムを書くための究極の奇策 – 「Data first, not code first」 | POSTD

    (訳注:2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars (忍者戦争)でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v

    より良いプログラムを書くための究極の奇策 – 「Data first, not code first」 | POSTD
  • コードの品質を維持したまま開発スピードを上げる | POSTD

    高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる

    コードの品質を維持したまま開発スピードを上げる | POSTD
  • コードレビューのベストプラクティス | POSTD

    Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

    コードレビューのベストプラクティス | POSTD
  • ソフトウェア開発で得た教訓22箇条 | POSTD

    1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い

    ソフトウェア開発で得た教訓22箇条 | POSTD
  • 優れたエンジニアを採用できないワケ | POSTD

    あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、

    優れたエンジニアを採用できないワケ | POSTD
  • すべてのプログラマが読むべき記事10選 | POSTD

    Javaプログラマやソフトウェア開発者として、私は「プログラマが知っておくべき…」というタイトルが付く記事から、多くのことを学びました。そういった記事は、特定のトピックに関する有益かつ詳細な情報を数多く与えてくれましたが、探し出すのが非常に困難でもあったのです。知識を探求する中でとても役に立つ記事を見つけたら、参考として何度も読み返せるようにブックマークしてきました。こういった記事を読むことは、どのプログラマにとっても有益になると思うので、私が集めた「 すべてのプログラマが知っておくべきこと 」を皆さんと共有する為にこれを書きました。 ここで紹介する記事は私が個人的にブックマークしたものです。「メモリ」、「Unicode」、「浮動小数点演算」、「ネットワーキング」、「オブジェクト指向設計」、「時刻」、「URLエンコード」、「文字列」などといった代表的なトピックについて載っています。このリス

    すべてのプログラマが読むべき記事10選 | POSTD
    yukatou
    yukatou 2014/06/27
  • 1