UI ファーストという開発手法 - 何気に大変
ソフトウェアエンジニアは新しく何かを開発する際に、技術的に可能かどうか、どう実装すればいいか、みたいなのを先んじて考えがちな気がする。 そういうボトムアップ的な思考は技術を知っているが故に出る自然な思考なのだが、私の経験上そういう思考で作られたものは大体使いづらい、いわゆる gomi が出来上がる。 なぜか？それは UI を考える際に実現可能性や実装のしやすさを優先してしまうから。 ここでいう UI とは WEB サービスやネイティブアプリなどに限らず、ライブラリなどであれば API を指す。 私は数年前から UI → 実装という開発順序で開発をしていて、それは以下のような感じ。 まず実現可能性を窓から投げ捨てる 素晴らしいと思う UI を考える その素晴らしい UI を実現するための実装方法を考える こういう感じで進めると、ほとんどの場合、素晴らしい UI を実現するための方法がすご
大学生が約3年間WebアプリとiPhoneアプリを合計16個リリースして感じた10個の事 - ゆとりIT
どうも。 何か情報発信をするべきなんじゃないかとふと思って久し振りに記事を書こうと思います。 ところで、私は大学1年生だった2011年の6月からWebアプリとiPhoneアプリを開発してきて、今までに16個のアプリをリリースしてきました。 内訳ですがWebアプリが10個、iPhoneアプリ6個で合計16個です。個という単位があっているのかはわかりません。 開発を始めたのは2011年6月で、2011年の3月にとあるWeb系の会社でアルバイトしていた時に「あ、Web楽しい」って思ったのがきっかけで、Webアプリ、そしてiPhoneアプリを作ってきました。 それまではWebといえば、しょぼいHTMLとしょぼいCGIくらいしか書けませんでしたし、あまり興味がありませんでした、というより自分にはできないと思ってました。 ずっとそれまではネットワークとかセキュリティが好きでちまちまPythonでスクリ
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ヘビメタ英語を日常で使う風景
