プログラマの第三の選択 - SonicGardenのビジネスモデルについて考える - メソッド屋のブログ
ソニックガーデンは、利益や、成長よりも顧客、エンジニア、経営者の幸せを求める革新的な形態の新しい企業だ。今後このような形態の企業が増えてくると思われるが、その先便の企業だと思う。 日本のソフトウェア業界の企業形態 日本のソフトウェア業界にある企業を３つに分類してみた。そして、その傾向を分析してみた。 A. モーレツな成長と成功を求める会社 これは２種類あり、スタートアップ系のベンチャーと、Amazon, Google, Facebook等既に成功し、成長したスタートアップ系企業だ。スタートアップの場合は、ほぼバクチのようなもので、当たり外れが激しい。最初の給料は激安。その代わり成功したときに入る収入は段違いだ。その代わり、生活はほぼ犠牲にされると思っていい。経営者もこれは同じで成功した暁には凄く大きなお金と、働かなくてもよくなるぐらいの自由が手に入る可能性がある。ただ、成功の確率はとても低
超高速開発 体験談 - 職業プログラマの休日出勤
数日前に日本で話題になっていた「超高速開発」について記事を残したいと思います。ニュース記事 超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 － Publickey の はてなブックマーク に寄せられたコメントを見る限り「食わず嫌い」な方が非常に多いように見受けられたので、これは体験談の需要は高そうだなと思い、書き始めた次第です。 ネタ記事を書いた直後に真面目な記事を書くのは、少し気が引けるものではありますが…。 私は2006年初頭から2012年初頭まで、インフォテリア社製の開発ツール「Asteria」を使用していました。この製品には冒頭で紹介した記事からもリンクが張られていますが、超高速開発を実現するためのツールの一つです。もちろん、私がAsteriaを使用していた頃は「超高速開発」などという言葉は見たことも聞
ゆーすけべー日記
ここ最近の僕の開発で指標になっているのは「システムとしてのクオリティを上げるか」であり、それって当然のごとく行われているかもしれなくて、いわゆる Quality Assurance = QA なんて言葉があったり、某社では Test Engineer の方がいたりするわけです。ただ、あまりにも僕としては「ずさんな」ところが多々あると考えています。「よしAを変更した → デプロイ → Bがエラー出てる」なんてことがないように「機能が望むように動作しているか」をテストコードで担保しようと努めている次第です。例えば、先日サービス内で使用している Flickr API の一部メソッドが正常に機能しない（ どんなに一般的な語彙で探しても検索結果が空で返ってくる ）なんてことがありましたが、テストコードのおかげで問題の切り分け、つまり、これは本当に Web API が壊れているのだ！ということがテスト
継続的インテグレーション入門 | Remote TestKit
ソフトウェア開発におけるQCDを高い次元で満足させるための手法の一つである、継続的インテグレーション(Continuous Integration)について学習します。 システム開発における課題 最近のシステム開発において、最も求められていることはなんでしょうか？ 以前から、QCD（品質、コスト、納期）といわれていますが、この三つを同時に満足することが困難であることは、ご存知かと思います。 品質を上げるためにはテストを十分に行う必要がありますが、そうすると、テスト工数が膨らみ、コストと納期が遅れる可能性があります。 納期を短縮するためには開発者の人数を増やす場合もありますが、「人月の神話」に代表されるように、人員を増やしてもある程度以上は生産性は向上しません。結果的に、コストが上がる場合も考えられます。また、納期を短縮するためにテスト工数を減らす、という対応をすることで、システムの品質が下
戦うプログラマによる戦略的アイデア量産テクニック
はじめまして！アシアルで開発を担当している四方と申します。 海上自衛隊・SIer勤務を経てアシアル株式会社に入社というちょっと変わった経歴を持っています。 そんな訳で私のエントリーでは通常の技術記事とはちょっと違った視点から開発Tipsを伝えて行けたらと思います。 戦略的にアイデアを量産するテクニック ITに限らず何かを作り始めるとき必要になるのがアイデアです。 今回は、私が前職でデスマっている際に偉い人から「1週間後までに、10億稼げる新事業のアイデアを50個出せ！」と言われた時に編み出したアイデア量産テクニックをお伝えします。 1.身近にある「不便」の解決 最もオーソドックスなアイデアの発想法です。 ハイマン・リップマンという人は、鉛筆と消しゴムを交互に使っているうちに消しゴムをよく失くしてしまうので、消しゴムと鉛筆をくっつけた消しゴム付き鉛筆を発明しました。 消しゴムと鉛筆をくっつけ
【質問】こんな条件の技術者を採用したいとなったら、どれくらいのオファーを出せばいいでしょう？
Javaは必須。フレームワーク(MVC・O/Rマッピング)の開発・メンテナンス経験があるのが望ましい。
スマホアプリの忘れちゃいけない5つのテスト観点 | DevelopersIO
こんにちは！おおはしりきたけです。今日はスマホアプリの忘れちゃいけないテスト観点について書いてみたいと思います。 はじめに 前提条件として、機能要件のテストは、やっている前提です。ここでは、テストの観点で忘れがちなポイントを備忘の為にも書いておきます。もっと深いとこ掘れば色々と細かいテスト観点というのは出てきますが、まずは、以下の5点を抑えておく必要があるかなと思います。 1.オフライン スマホはオンライン/オフラインの切り替わりが頻繁に起きます。たまにオフラインだとローディングのままずっと返ってこないアプリありますよね？そういったアプリはオフラインの場合を想定していない為、タイムアウトにもならなかったりします。オフライン時のリクエストでどのような動きになるのかをしっかりと確認する必要があります。オフラインで動くところ、サーバーにリクエストを投げるのでオンラインじゃないと動かないところなど
PHP,Ruby,JS,HTML,CSSをブラウザ上で開発できるオープンソースIDEエディタ「ICEcoder」:phpspot開発日誌
PHP,Ruby,JS,HTML,CSSをブラウザ上で開発できるオープンソースIDEエディタ「ICEcoder」 2013年05月24日- Browser code editor awesomeness : ICEcoder PHP,Ruby,JS,HTML,CSSをブラウザ上で開発できるオープンソースIDEエディタ「ICEcoder」 ブラウザ上だけどツリービューでファイルを開けたり、タブでファイルを複数開けたりIDE顔負けのインタフェースを持つエディタ。 OSSなので自分のサーバに設置して使うことができます。リモート開発の方法は色々ありますが、Chromeだけでサクサク開発するっていう手法もなかなか便利なのかも。 こういうのを１０年ぐらい前の人に見せてあげたいですね。 そういう意味では１０年後が恐ろしかったりします。 関連エントリ フルスクリーン編集可能なWYSIWYGエディタ実装jQ
TeedaでHTMLプロトタイプを作成する際のガイドライン - 出羽ブログ
このエントリーの内容を下記のページに反映させて頂きました。 http://teeda.seasar.org/ja/html_for_prototype.html お客様と外部仕様を確認する目的でプロトタイプを作成するフェーズにおいて、TeedaのHTMLテンプレートを作成する際の注意点を自分なりにまとめてみました。 外部仕様を明確にするためにある程度の作り込みはしますが、このフェーズでHTMLテンプレートを最終形態まで作り込むことは想定していません。 重要事項 文字コード（推奨） UTF-8 HTMLファイルの命名規約 HTMLファイルは、ラクダ文字（１文字目は小文字）にします。 良い例 hogeFuga.html 悪い例 hoge_fuga.html 拡張子 Teedaに認識させるHTML .html Teedaに認識させないHTML .htm コンテンツの形式 xhtml形式 参考UR
顧客を満足させ続けるプラクティスについて
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
サイボウズOfficeでZipファイル生成を実現するまで - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。サイボウズ Officeの開発を担当しています、佐野です。 みなさんよくご存知のZipファイル。ユーザーとして展開や圧縮の方法はよくわかっていても、プログラムとしてどうやって作られているのかを知る人はそう多くないと思います。今回は、この「どうやって」について開発経験をもとにお話します。具体的には、弊社がクラウドサービスとして提供しているサイボウズ Office on cybozu.comでの実現の過程を取り上げます。 今回扱う内容は広範囲に渡っていて、設計、実装、パフォーマンスチューニングなどに触れます。開発当初の期待とは裏腹に一筋縄ではいきませんでした。実際のソフトウェア開発ではよくあることですね。その点についても後ほど詳しく紹介します(実はここが一番面白い所です)。内容は全般的にプログラマー向けですが、プログラマーでない方も、開発過程の雰囲気だけでも楽しんでいただければ幸い
ソフトウェア開発のリーダーが持つ三つの責務 - @ledsun blog
ソフトウェア開発のリーダーが持つ三つの責務を以下に定義する。 技術 タスク管理 教育 技術 開発中に出てきた技術的な課題を解決する必要がある。マネージャーならできる人に任せてもいいけど、リーダーなら自分で解決しないとね。そのためには、日頃から未知の課題を解決するためのアンテナを鍛えておく必要がある。さらに、進捗が遅れた時は伝家の宝刀を振り回す*1必要がある。そのためには、直近の仕事で使わない技術も素振って*2おいていつでも使えるようにしておく必要がある。 タスク管理 メンバーはタスクを振らないと仕事しない。メンバーにタスクを振って進捗を上げつつ、リーダーは残タスクを把握しておく。タスクに抜けがあると開発が完遂できない。また遅れを検知して対応する必要がある。技術的に難しすぎたり、作業量が多すぎたり、メンバーの力量を超えるタスクだった場合は伝家の宝刀を振る必要がある。また、メンバーの能力によっ
スマートフォン開発研修教材の公開について - mixi engineer blog
クラフトワークの来日公演3-D CONCERTS 1 2 3 4 5 6 7 8を観にいったら、顔が大きいのか、3Dメガネがきつくて切なかったもりもとです。 株式会社ミクシィでは、新卒入社スタッフをはじめ、これからスマートフォンアプリ開発を行っていく全スタッフを対象に、社内で「スマートフォン開発研修」を始めています。その研修資料をこのたびgithubで公開させていただきました。 mixi-inc/iOSTraining · GitHub https://github.com/mixi-inc/iOSTraining mixi-inc/AndroidTraining · GitHub https://github.com/mixi-inc/AndroidTraining これら文書は、それぞれCC BY-SA 3.0およびApache License 2.0とCC 2.5 Attributi
最低限知っておきたい仕様書を書くときの３つのポイント 【ボクバイＺ the blog】
こんにちは。ライブドアでブログを更新しているキツネハンターです。 今回はソフトウェア開発に必要となる「仕様書」を書く際のポイントについて紹介したいと思います。あと、このテイストはlivedoor ディレクター Blogのパクリです。 さて、仕様書と言っても、大別して２種類あることをご存知でしょうか？１つはユーザー側から見た外部仕様（機能仕様）、もう１つは開発者側から見た内部仕様（技術仕様）です。 例えば、「0〜100までの素数を全て求めたい、素数を数えて落ち着くんだ」というのが外部仕様。これに対して、「ある数Ｘ（Ｘは0以上、100以下）を２からＸまで順に割ってアレする」というのが内部仕様。 外部仕様を書くのはカンタンです。たぶん、誰でも書けます。でも、内部仕様を書くのはプログラミングのスキルがないと書けません。内部仕様を書けるのは、プログラマーかスーパープランナーだけです。 ボク
ソースの自動生成に関する本質的な違和感 - プログラマでありたい
定期的に出てくるテーマの一つにソースコードの自動生成ってのがあります。 私としては、強く強い違和感を感じます。一言で言うと、自動生成出来るレベルなら、そもそもコードを書く必要がないんじゃないと。Rails等の最近のフレームワークで言うと（Railsが最近のフレームワークかどうかは置いておいて）、自動生成というより決まりきったことはそもそも書かないで済ます方向にあると思います。そこに自動生成のコードで生産性がアップしますよと言われても、違和感ありありです。 私がソースコードの自動生成に否定的な理由は、下記の3点です。 ・自動で生成出来るような内容は、そもそもソースとして必要ないのでは？ 自動生成出来るレベルのソースは、ソースとして生成する必要がなくなっています。 周りくどい言い方ですが、既に定形となっているので機能の一つとして呼び出してしまえば良いのです。 ・開発に占めるコーディングと、微調
バッチで，コーディング規約を守らせよう （全ソースコードをチェックして，ルール違反を自動検出） - 主に言語とシステム開発に関して
バッチのまとめTOPへ 「コードの読みやすさ」は，非常に重要だ。 ソースコードが読みづらくなると，コードが「仕様を表現」しなくなる。 簡単にバグが混入され，埋もれてしまう。それに気付きもしなくなる。 保守や改良ができなくなる。 プロジェクトが行き詰まる。 デスマーチが始まる。 ・・・ 逆に，「読みやすいコード」でさえあれば， どれほど多くのバグが混入しているとしても，容易にすばやく修正できる。 保守性が高いのである。 「読みやすいコード」は「仕様を明快に表現しているコード」なので， 他の人が読んだ時，仕様の誤解が起こらない。手をつけやすい。 「把握しやすいコード」は「変更しやすいコード」なので，プロジェクトがどんどん前に進む。 でも，それを確保するにはどうしたらよいのか？ 「コードの読みやすさ」を確保するには どうしたらよいか ひとつの方法 補足 「コードの読みやすさ」を確保するには 上級
Windows PCと仕事机をセットアップする際の手順の記録 - 主に言語とシステム開発に関して
PCと，仕事机周りの環境をセットアップするためのチェックリスト。 OSはWindows Vistaを想定し，開発環境を構築するための作業手順。 新しいPCや新しい机になったら，毎回，このチェックリストに従って素早く作業する。 開発現場での「初日」をスムーズに消化する事が目的。 （１）IEからFirefoxへ乗り換えて，セットアップ手順を開く （２）基本的なファイルシステム等の整備 （３）ブラウザの整備 （４）開発資材の整備 （５）PC内の仕上げ （６）机周り 事前にしておく事 頂きたいマシンの要件を伝える OSバージョン 32ビット/64ビット パーティション：C:, D: の２つ Microsoft Officeの必要性，バージョン 管理者ユーザアカウントの必要性 メモリ，CPU，サウンドカード，HDD容量 NW：どのサブネット上に置いてほしいか 必要なプロダクトキー類 まっさらのマシン
開発用のフォルダ構成を，自動的に生成してくれるバッチ （プロジェクト用のリポジトリ立ち上げに便利。ついでに，用が済んだら自動消滅！） - 主に言語とシステム開発に関して
ソフトウェア開発のためのフォルダ構造を，自動的に生成するバッチ。 例えばSVNリポジトリの立ち上げ時などに，ワンクリックで，チームで作業可能な開発プロジェクトのひな型を生成することができる。 毎回同じようなフォルダ構造を手動で作るのは面倒なので，自動化する。 具体的には下記のように，各開発工程に対応したフォルダが作成される。 各フォルダは複数のサブフォルダを持つ。 詳しいフォルダ構造の中身は，エントリの後半を参照。（カスタマイズ可能） 01_立ち上げ 02_要件定義 03_基本設計 04_詳細設計 05_実装 06_試験 07_リリース 08_運用 09_移行 10_その他 99_マネジメント 開発者に対して「作業開始を促す」ため，各サブフォルダにはTODOファイルが設置される。 これはプレースホルダの役目を果たす。 このようなファイルセットを，一発で生成するためのバッチ。 ソースコード
同じ開発チームの「批評家」とどう接すべきか悩んでいる
同じ開発プロジェクトのメンバーに、頭でっかちで、口は達者だが、まったく手を動かそうとしない、いわゆる「批評家」な人が居る。その人とどう接したら良いのかわからず、悩んでいる。（以下、「先生」と呼ぶ） 先生はあまり技術スキルが高く無かった。先生が担当する部分のシステム仕様や、そのシステムに関連するスキルの習得状況が芳しくないことと、そもそも基本的なプログラミングスキルも、低いとは言わないが、安心してまかせられるレベルではない、ということが分かってきたため、最終的には、スキルが求められる部分については、分割して他の人が分担して持つことになった。 先生はそれなりに時間ができ、スキルアップのために技術書を読み始めたようだった。それはとても良いことなのだが、どちらかというと、はじめての◯◯、とか、猫でもわかる◯◯、等を読むべき技術スキルだったにも関わらず、読み始めたのがデザインパターンやリファクタリン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kayac/newbie-training
