私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ15年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか?ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
■ リーダブルコード入門 プログラム経験のある方が、リーダブルコード(※1)を書くために必要な考え方を学ぶ事ができます。 今回は、名著「リーダブルコード」の解説者である須藤先生と一緒に「3章 誤解されない名前」を読みながら、よい名前のつけ方について学びます。 ■ 対象者 プログラミング経験者で、リーダブルコードを書きたい方 変数や関数の命名に自信が持てない方 自分のコードを他の人にとっても読みやすいコードにしたい方 ■ 関数や変数で『誤解されない名前』を付けられるようになろう プログラミングを行うと、変数や関数に名前付けする機会が沢山あります。 でも名前のつけ方って、まわりの人に聞いてもなかなか明確な答えを教えてもらえませんよね? 「うーん、自分も難しいなぁと思っているんだよねぇ」 「ケースバイケースだからなぁ」 「今回はA案の方がいいかなぁ」 でも、ベースとなる考えを持っていれば、よい名
今日よく知られているプログラミングの多くは、古い言語として取り上げられるに十分な歴史を持っている。PHPは20年、Pythonで23年、HTMLは21年で、RubyとJavaScriptは19年だ。Cなどは42年もの歴史がある。 誰もこの様な事になるとは思いもしなかっただろう。今でも出版されている、世界で最初のCの教本の共著者であるコンピューターサイエンティスト、ブライアン・カーニハンですらだ(C自体は同じ本の共著者であるデニス・リッチーによるものだ。彼は2011年に亡くなっている)。 「編集者とこの本を5000部売れたらなという話をしたのをなんとなく覚えている。もっといいものにも出来たが、学生が2014年になってもあの本を使っているなど考えもしなかったことだ」と、カーニハンは最近のインタビューで答えてくれた。 Cがあまりに長く使われていることから、グーグルが今でもCを使って解決する問題を
TOPICS Programming , Business/Essay 発行年月日 2009年04月 PRINT LENGTH 284 ISBN 978-4-87311-402-6 原書 The Productive Programmer FORMAT PDF 生産性の高い人はそうでない人に比べ、同じ時間でより多くの仕事をし、より多くの成果を上げることができます。本書は、ソフトウェア開発におけるプログラマの生産性についての書籍です。プログラマ個人が、どのような意識を持ち、どのようなツールを使えば、単位時間当たりの仕事量を増やすことができるかについて示します。本書は2部からなり、「I部 技法編」では、作業を自動化するためのツールや集中を維持する方法など、開発に必要な作業の生産性を向上するテクニックとツールを解説します。「II部 実践編」では、テスト駆動開発や、メタプログラミングなど、生産性を
はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指
2017/9/23に開催されたUnity道場スペシャル 2017幕張の講演動画です。 講師:石井勇一(ユニティ・テクノロジーズ・ジャパン合同会社) 講演動画:https://youtu.be/fy2VGj-_s6U 企業、学校などで様々な場所でUnityが活用されています。それに合わせてUnity研修のニーズも高まってきます。2014年頃から企業向けUnity研修を企画・実施してきてた経験から、講師の方向けにUnity研修の組み立てのヒントになりそうなことをお話しいたします。 こんな人におすすめ ・Unity研修の企画/制作/実施をする方 受講者が得られる知見 ・Unity研修組み立てのヒントが得られる Unityのイベント資料はこちらから: https://www.slideshare.net/UnityTechnologiesJapan/clipboards
データの流れが見える新プログラミング言語「Flower」を開発した学生プログラマたちが目指すこと #flowerlang 2014.03.19 Category:【連載】ギークたちの『仕事の流儀』 Tag:FLOWer ,プログラミング言語 福岡県Ruby・コンテンツビジネス振興会議が2月に開催した「福岡ビジネス・デジタル・コンテンツ賞2014」で、「ヤング賞」を受賞した株式会社Technical Rockstarsが作った新たなビジュアルプログラミング言語「Flower」。 「Flower」開発者である部谷修平氏(同社CEO)、花田恒一氏(同CTO)に開発の狙いや、これからの取り組みを聞いた。 by 馬場美由紀 (CodeIQ中の人) いちいちソースコードを書くのは面倒くさい 「Flower」はデータの流れを見ながら、簡単なマウスや画面タッチ操作でプログラミングができる、新世代のビジュア
プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく2つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その2つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は12種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。 ( 注:ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供し
久しぶりに勉強会に参加して喋ることになりました。長年開発に携わっている「あすけん」の勉強会です。 発表内容はあすけんとは直接関係ありませんが、普段どのような開発をしているのか数字を交えながら紹介したいと思っていますので、よろしければぜひご参加ください。 asken.connpass.com 副業から開始したアプリ開発で起業し12年が経ちました。スモールビジネスとしてどのように会社を経営してきたか、いちモバイルエンジニアの生存戦略を会社やアプリの売上、受託開発の開発単価等を交えながらご紹介します。 先日、AppStair株式会社を株式会社メタップスに売却しました。 創業から4年でのバイアウト(弊社的にはセルアウト)になりました。 AppStairは前職時代に個人で開発していたアプリ(Best Album)をフルタイムで開発してみたいという理由から創業した会社で、何かイノベーションを起こしたい
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く