少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
HTMLやJavaScriptでWindows/Mac/iPhone/Androidアプリを開発するフレームワーク「Appcelerator Titanium 1.0」公開 | OSDN Magazine
米Appceleratorは3月8日（米国時間）、オープンソースのアプリケーション構築プラットフォーム「Appcelerator Titanium 1.0」の一般提供（GA）を開始した。HTMLやJavaScriptなどを用いてモバイル/デスクトップ向けアプリケーションを開発できる。 TitaniumはHTML、JavaScript、Python、Ruby、PHPなどのWeb技術やスクリプト言語を使ったアプリケーション開発を行うためのフレームワーク。iPhone/AndroidアプリケーションやWindows/Mac OS X用のデスクトップアプリケーション開発に対応する。同様の技術にAdobeの「AIR」があるが、TitaniumはアプリケーションのサイズがAIRの10分の1程度と小さいのが特徴としている。 iPhone/Android向け開発では、iPhone SDKやAndroid
いまからでも間に合う開発者テスト - mixi engineer blog
はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、
[ソフト開発] わかりやすいプログラムの書き方 - よくわかりません
※このエントリは、Arata Kojima/NPO法人しゃらく さんが公開しているわかりやすい技術文章の書き方の改変です。 このページは、プログラムやコードなどを書く方々のために、分かりやすいプログラムを書くためにはどうすればよいのかについて説明しています。 1. 自分が伝えたいこと・訴えたいことを誤解しないように相手に読んでもらうにはどうするべきか。 2. プログラムを書くにあたって知っておくべきルールは何か。 3. プログラムを書く前にどのような手順を踏めば、分かりやすいプログラムを作れるか。 などについて参考にしていただければ幸いです。 プログラムを書く前に プログラムを書く前に次のことをしっかりとイメージしておく。 何を書くのか。 書こうとしている物は正確に何であるのか。 仮定して良い、必ず成り立つ前提（状況／状態）は何か。 成り立つ事が単に多いだけ／今はたまたま成り立っている、と
「このサイトと同じものを」の危険性 - がるの健忘録
以前から何度もあった話なのですが…ちょいとかみ砕いて。 まず。 「このサイトと同じように作ってください」という発注は、原則NGだと思っています。ここが結論。 高確率で「無考察」という背景が見えるから、というのが理由になるのですが。 以下、もう少々かみ砕いて。 上述の発注が来た場合。作業としてはまず「指定されたサイトの仕様調査」になるわけなのですが。 いわゆる「画面遷移」ひとつをとっても。コンパクトなサイトであっても、数十Pageに渡るなんてのは案外にさらっとある話です。 正直、全Pageなめ回して、抜けオチがないようにチェックするだけでも一苦労ですし。ある程度まで「使ってみて」、様々な分岐処理を全部洗い出した上で確認しなければならないので。 結果として…おそらく、発注側が気軽に使っているニュアンスとは裏腹に、大抵の場合「結構な高コスト」になります。 …という話をすると大抵出てくるのが「そこ
上流の技術者はSQLを高いレベルで習得すべき：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 まともな議論になっています。炎上というのはコメントをつけてくれた方々に失礼かもしれませんが、何回も炎上してきたし、何回も同じことを書いてきたし、それどころか10年言い続けてるし……。 がしかし、この業界のお客様から、このようにご意見を頂戴した（わたしが猛烈に望んでいたコメントなんですけど自作自演じゃないからね）。 http://el.jibun.atmarkit.co.jp/g1sys/2009/06/vb6-8111.html#comment-24715757 そこで、以前からの蒸し返しですが、「上流の技術者はSQLを高いレベルで習得すべき」と改めて一度、声を大にして言いたい。 その前に余談ですが、VB6と.NET（とSQL）について。 どっかでコメントしまし
プログラミングだけできればいい、なんてことは無いさ。 - GoTheDistance
なんで管理について書きたいのか 動機です。 単純に「プログラミングだけできればいい」「SIする人は要件定義だけやれ」という声を聞くと切ないからです。 ただし、わたしは個人的に、開発というお仕事においてプログラミング技術が何を差し置いても最重要だと思っていますから、その軸は絶対にぶれない、ということを念押ししてから始めたいと思います。 ひとりにはなりきれない空を見あげる これも昔思ったことなので、取りとめも無く書いておきたいと思います。 技術リテラシーが死んでいる人間が立ち上げた or 回しているプロジェクトは高い確率で砂上の楼閣のように崩れ落ちていく。だからプログラミング技術に代表される技術リテラシーは必要不可欠。だけど、全員が全員その道を突っ走ると今度はビジネスにならない。取ってきたシーズをプロジェクト化できない。僕は後者が出来ない自分でありたくないという思いから、スーツ的な何かを２年ぐ
デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 - 角谷HTML化計画(2009-02-12)
Invalid Text■<%=sn number %> <%=flickr_left '3274768929' %>デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 つかれたのであとで書く。とりあえずスライド。最後までスライドめくれてよかった。 写真はtakaiのを借りてます。練習不足(というかスライド完成したのが10分前)でリモコンを見すぎてしまいました。情けないです。 The way to the timeless way of programmingView more presentations from Shintaro Kakutani. (tags: devsumi2009 xp) slideshare.net kakutani.com よくある質問と答え Q:動画はいつ公開されますか？ A:録画してません。 Q:予稿とかないの？ A:ありません。ひとえ
Webアプリ開発における「内部APIモデル」 - Tous Les Jours 攻防記
前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは２つあります。 （１）言語やフレームワークの選択自由度が上がる 現在運
プログラミングテクニックのまとめ - プログラミング日記
とりあえず思いついたもののまとめ。 まずは、ベーシックなものから。 変数のスコープをなるべく狭くしろ 他はグローバル変数を使うなとか、モジュール化と界面を意識せよなど。とにかくスコープは重要かつ意外と奥が深い。スコープに関係する機能は、モジュール(パッケージ)、クロージャ、ローカル関数、ローカルクラス、変数の種類、アクセス制御など。 同じロジックのコードを2度以上書くな 他はDRY原則、コピペをするななど。自分の場合、2度書く方がシンプルになる場合、2度書くこともある。特に、ifやswitchなどのロジックの中で同じコードが2度現れる場合、ちょっとしたコードでわざわざ別のところで関数やブロックにまとめて、それを参照するのは面倒。但し3度以上現れる場合は関数などにまとめるケースが多いかも。 汎用コード内で条件分岐コードを減らせ 他はifをポリモーフィズムによりなくせなど。条件分岐は汎用性を損
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
