技術選定の審美眼。時代を超えて生き続ける技術と、破壊的な変化をもたらす技術を見極める（前編）。デブサミ2018 － Publickey
最近の立ち位置としてはライオンと一緒にされていまして、テストを書いていないプルリクエストとかに対して、却下の代わりにこの画像が張られるみたいな形で、一種の恫喝の代わりに使われています。 が、本人はきわめてジェントルな人で、いましゃべってるところを見て、このライオンとはキャラが違うなとお感じになっていただければ嬉しいです。 ついて行くべき変化とスルーしていい変化 昨今の技術の現場でよくあるのは、フロントエンド疲れ。JavaScriptの新しいフレームワークや、開発方法論とか、そういうのがどんどん登場して、また新しいものが出てきたと。 2年前に標準とされていたものがすっかり過去のものになってしまっていて、Gruntはどこに行ってしまったんだとか、Backbone.jsはどこに行ってしまったんだとか。 そうした変化に追いつけずに、疲れてしまうわけです。 かと思えば、一種の限界集落。よく言えば安定
技術選定の基準は課題解決
多様性あふれる世界なので、ひとえに技術選定と言っても様々な理由でされるかと思います。 そんな中、自分は 過去直面して苦労した事がある課題を解決させるため という理由で技術選定を行ってきました。 例えばどんな技術を選定している？ Go言語 サーバーを実装する時はGoを使っています。 理由は サーバーを開発/運用してて、複雑で色々できる言語よりも、コード量が多くなってもいいから単純でやれることが少ない言語が良い と思ったからです。 サーバーサイドはインプットとアウトプットの形式が限られ（ほぼJSON）、更にデータ破損という最悪のケースを防ぐために堅牢でわかりやすいロジックを書くことが推奨されます。 そう考えると継承等の機能がなくて個性が出にくく 誰が書いたかわかるコードではなく、誰でもわかるコード になりやすいGoが選択肢に挙がりました。 もちろん速度が出る、シングルバイナリ、並列処理が書きや
システム開発における技術選定とは？観点などを解説します【エンジニア】
システム開発における技術選定とはこの記事でいう技術選定とは、その名のとおり「どんな技術を使うかを選ぶこと」です。領域はインフラやサーバーサイド、フロントエンド、また種類としては言語やフレームワーク、ミドルウェアなどが対象になります。 この記事ではライブラリの選定基準については書いていません。これについては「ライブラリの選定基準」で詳しく書いていますので、あわせてご覧ください。 なぜ技術選定をするのか技術選定の目的は「事業価値を最大化するため」だと考えています。技術選定というと、ついシステム要件を満たすために決めてしまいがちです。もちろんこれも必要ですが、選定の観点という意味では一部でしかありません。 企業において、開発は事業を運営するために行います。OSSの場合は「事業」を「ソフトウェア」に置き換えられると思いますが、使う技術は事業に大きく影響します。たとえば、技術を使える人の採用コストだ
理想の技術選定 | timakin（ちまきん）
個人的に技術選定について想いを馳せた記事です。 技術選定と妥協最近とても技術選定について悩んでいます。技術選定とは常にジレンマを伴い、各エンジニアの感情がぶつかり合うセンシティブなトピックです。 技術選定が「悩む価値のある問題」であるのは明確で、サービスそのものの市場領域を選ぶときほどではないけど、開発組織が長期に渡って健全にワークするか、というのを決める、非常に重要かつ長期にわたる問題だからです。 加えてこれは個人的な話ですが、僕は自分のエンジニアとしての性格なのか、「ビジネスとしてうまくいくスピード感があるのか、明確な課題があってそれを解決しているのか」という意見は前提にしつつ、ある程度技術的新規性に重きを置きがちなタイプという自覚があります。 なので、僕個人は技術選定となると、新規技術の導入に逸る気持ちを意識して抑えなくてはならないことが多いです。ただ別にそこまでネガティブな感情を覚
技術選定の時に気を付けること - Qiita
新技術の話をしたときに、僕がいつも話すことをまとめてみました。気になるところとか、突っ込みどころがあれば、コメントいただきたいですm(_ _)m 技術選定時に気を付けること 現場に残る人たちが使いこなせるのか？（選定した人が抜けても機能するか？） ブラックボックス的に使うなら、十分に枯れているか？（10年以上が節目？） シンプルさや、使用感の統一性、既存技術との乖離性（手続き型と関数型など）などを考慮 高負荷時の動作など大丈夫なものか？（高負荷になるとバグが出たりします。。。） 既存技術と比べて大きな優位性があるのか？ 頑張って選んでも、数年後には古いと言われます。。。 影響範囲が狭くて、修正頻度が極端に低いのであれば、とりあえずGoでもおｋかと。 スケールアウト出来るとはいえ、実行速度が速い言語のほうが良いと思います。（プロトタイプ制作なら作りやすいものが良いかもですが。。。） など、色
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
