ソフトウェア例え話、格言、小噺 - from scratch
2016年になってから色んなソフトウェアエンジニアの人と話してきて、その中で3人から聞いた例え話、格言、小噺が面白かったので、僕の中だけで留めておかずに開放しておく。 息継ぎをするには『まず息を吐く』という例え話 水泳で息継ぎをするなら『まず息を吐きなさい』と教わるらしい。これは息を吐かずにどこかで息を貯めてしまうと、ちゃんと息を吸えないという事を意味してる。息を吐くと苦しくなって顔は絶対に水面に出る。 これと同じことがソフトウェアの学習にも言える。 つまりまずアウトプットする、なんでも良い。作ったものをGitHubに公開するとか、発表するとか、ブログやQiitaに書くとか。ちゃんとアウトプットしたものはフィードバックがあり、そのフィードバックを受ける(PRやissue, 質問, マサカリ etc)、どんどん吐き出していくと吸わないとネタがなくなるので、吸い込むためにまたインプットする。
CSSになり損ねた言語たち | POSTD
TeXやMicrosoft Word、あるいはその他の汎用的なテキスト処理環境では簡単に実現できるような見た目に自分の文書を似せようと頑張る（文字どおり）無数の人たちに対して、 “悪いけど、うまくいかないよ” と繰り返し言い続けるのは、実際のところ、この1年間、私にとっては継続的な楽しみだった。- Marc Andreessen 1994年 Tim Berners-LeeによってHTMLが発表された1991年には、ページのスタイルを設定する方法はありませんでした。HTMLタグがどのように処理されるかはブラウザ次第で、多くの場合、ユーザの恣意的な入力が大きく影響しました。そうした事情から、ページがどのようなスタイルで処理されるかを”提案”するような標準的な方法を求める声が上がるようになりました。 しかし、CSSが導入されるのは5年先で、完全に実用化されるには10年の歳月を待たねばなりません。
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
5分で絶対に分かるAPI設計の考え方とポイント
API設計を学ぶべき背景と前提知識、外部APIと内部API、エンドポイント、レスポンスデータの設計やHTTPリクエストを送る際のポイントについて解説する。おまけでAPIドキュメント作成ツール4選も。 【0分】API設計を学ぶべき背景 APIの公開が増えている 最近、自社で保有するデータや、システム、アプリケーション、Webサービスの機能を「API（Application Programming Interface）」として公開する企業が、増えてきています。これに伴い、「API経済圏（APIエコノミー）」という新たなビジネスモデルが確立されつつあります（参考：5分で絶対に分かるAPIマネジメント、API経済圏）。 「ProgrammableWeb」というAPIに関するニュースサイトや、さまざまな企業が提供するAPIのリンクがまとまったサイトもあり、APIの普及はものすごいスピードで進んでいる
ウェブのプッシュ通知、何がそんなにすごいのか？
3 月 13 日、Chrome Beta のブログポストが出ました。Android 版 Chrome でプッシュ通知が使えるようになったのが個人的なハイライトです。 「確かにプッシュ通知は便利かもね〜」と思ったあなた、驚きが足りません。のけぞるべきです。小躍りするべきです。 理由を説明します。 ユーザーエンゲージメントが変わる # あなたのウェブサイトのビジネスモデルが広告モデルにしろ課金モデルにしろ、ユーザーが繰り返し訪れてくれることは大前提です。通常のウェブサイトやサービスは、そのための策を練ります。そのきっかけをサービス側から能動的に与えることで、ユーザーが戻ってきて、ビジネスは回ります。しかし、そのきっかけを与える方法は、非常に限定されていると言わざるを得ません。 インターネットが普及し始めた当初から伝統的に利用されているのがメール、数年前から利用されているのがソーシャルメディア、
Deep Visual-Semantic Alignments for Generating Image Descriptions
Deep Visual-Semantic Alignments for Generating Image Descriptions We present a model that generates natural language descriptions of images and their regions. Our approach leverages datasets of images and their sentence descriptions to learn about the inter-modal correspondences between language and visual data. Our alignment model is based on a novel combination of Convolutional Neural Networks o
デザイナがエンジニアリング（プログラム）を学ぶコツ | fladdict
最近、色々な方と「表現とエンジニアリングの融合」について、お話を伺ったりしたことからのまとめ。 なぜ表現者はテクノロジーを学習するのが苦手か 表現とエンジニアリングができるハイブリッドな製作者は、理系あるいはエンジニア出身の人間が多い。逆にアーティストや（グラフィック）デザイナーのバックグラウンドから、ハイブリッド型へと移行する人は相対的に少ない。 基本的には、エンジニアのほうが「系統立てて学習する」という点で、ノウハウと教育がある。いわゆる「美的センス」といわれるようなモノであっても、いちどロジック化して自分なりに消化さえできてしまえば、エンジニアは表現やデザインもエンジニアリングの一貫として学習することができる。（逆に、スキルをブレイクダウンして学習するぶん、「作れるけど作りたいものがない」になりがちではある。） 明確なビジョンが学習を阻害する 一方アーティストやデザイナが、なぜテクノ
フロントエンド技術者が会社とどう関わっていけばいいのかという話 - ダーシマ・ヱンヂニヤリング
今日はフロントエンドの仕事について考えていることを書く。フロントエンドの人間としてどのように会社と関わればいいのか、あるいはフロントエンド以外の人達に何を求めるか、そのような人たちとどうコミュニケーションをとって行ったらいいのか、などという事を中心に。 結論としては、やっぱりチームとしてモノを作っている意識を、みんなで持とうよということだった。 わたくしダーシマはネコメシに入る前、たぶん平均的な受託系ウェブ制作会社で２年半くらい仕事をした。フロントエンドとバックエンドが主で、ほんの少しだけディレクション業務もかじった。そこでは分業制が基本だった。ディレクターがクライアントと要件を詰め、デザイナーが絵を作り、場合によってはプログラマーがバックエンドをつくり、コーダーがコーディングをする。いわば、きちんとしたウォーターフォールでプロジェクトを進めていた。一人で複数の役割を担うことはあれど、世の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The New Norm of The Web
人は一ヶ月でエンジニアになれるのか - 詳細解説