百伊蔵のブログ(´・ω・`)

育児しながらプログラム勉強中です

Visual Studio Codeの新規ファイル作成ショートカット(Ctrl + N)の挙動を変える

Windows環境でVisual Studio Codeを使って作業しているのですが、新規ファイル作成をするショートカット(Ctrl+N)のデフォルトの挙動がどうにも不便でした。 これを、うまいこと素敵な挙動に変更できました!ということで、そのメモです。

■元の挙動 まずは、現状のショートカット操作での不満点です。

Visual Studio Coeeで Ctrl + Nを押すと、デフォルトでは無題のドキュメントが新しいタブで追加されます。 しかし、このタブは、まだファイルとしての実態はありません。 ですので、ファイル拡張子に応じたシンタックスハイライト等も当然機能しません。 そこで、保存しようと思ってCtrl + Sショートカットキーを押してみると、Windowsのファイル保存ダイアログに飛ばされてしまいます。

このダイアログのデフォルトのフォルダは、常に現在開いているプロジェクトのルートフォルダになっています。 ですので、適切なフォルダに移動して保存が必要なのですが、Windowsのファイル保存ダイアログの操作はキーボードだけでは難しいため マウス操作が求められます。

これが面倒くさい!

せっかくプログラムをノリノリで作っていて、ただただ同じフォルダに新しいクラスを追加するためにプログラムを追加したいだけなのに以下の操作が必要です。 1. Ctrl+Nを押すと、無印のファイルが作られる 2. Ctrl+Sを押すと、Windowsの保存ダイアログが表示される 3. マウスで適切なフォルダに移動して、 4. マウスでファイル名欄にカーソルを移動させて、保存ボタンを押す

マウスに持ち替えないとイケナイだなんて!! アリエナーイ!! ノリノリのプログラミング作業で、リズム感途絶えるわーーー・・・(´・ω・`)

■修正後の挙動

この非常に面倒な挙動が、keybindings.json に以下を追加するだけで解決出来ました! ※既存の Ctrl+Nショートカットの動作を書換えています

[ { “key”: “ctrl+n”, “command”: “explorer.newFile” } ]

コレを追加すると以下のような挙動になります。

  1. Ctrl+Nを押すと、Visual Studio Codeのエクスプローラーで現在の作業フォルダに新規ファイルが追加され、ファイル名入力待ち状態となる。
  2. 適切なファイル名を入力してEnterを押すと、新規ファイルが作成され、すぐ編集が開始出来るようエディタに開く カーソルも新しいファイルに移っているので、後は書き始めるだけ!

すばらしい!2ステップです!

これで、新規ファイル追加のたびにマウスに持ち替えなくても良くなりました!(∩´∀`)∩

ノリノリプログラミングも、そのままのリズム感で作業出来そうです!素晴らしい! もう、製品のデフォルトをこの挙動でお願いします!!

Angular4時代にAngular-CLIでAngular2の雛形を作る

angular は、2系から CLI (コマンドラインのインターフェース)を使って、アプリケーションの雛形を作ることが出来るようになっています。

このツールは angular cli という名前です。

最近、こうした形式のプログラミングツール多いですね。 慣れるまでは、「なんでプログラム書き始めるまでに、こんな幾つものコマンドを覚えて実行しないとダメなのか」とクラクラしたものでした。

かると便利なんですけどもねー。 変化への適応能力落ちてるわー(´・ω・`)

最新の angular-cliは、1.0.3 になっています。

GitHubのページを見ると、インストールは以下のコマンドで実行することになります。

npm install -g @angular/cli

これで ng コマンドが使えるようになり、ng new で雛形を作ることが出来るようになります。 が、、、生成される雛形は、angular 4.0 を使ったものになります。

生成された雛形のpackage.json を見ると、以下のようになっています。

“dependencies”: { “@angular/common”: “^4.0.0”, “@angular/compiler”: “^4.0.0”, “@angular/core”: “^4.0.0”, “@angular/forms”: “^4.0.0”, “@angular/http”: “^4.0.0”, “@angular/platform-browser”: “^4.0.0”, “@angular/platform-browser-dynamic”: “^4.0.0”, “@angular/router”: “^4.0.0”, “core-js”: “^2.4.1”, “rxjs”: “^5.1.0”, “zone.js”: “^0.8.4” },

では、angular 2系の雛形は、どうやって作れば良いのでしょう?

この答えが分からずに2時間程ハマってしまいました・・・。 オプションや環境変数などで、angularのバージョンを指定出来るのでは?と思い調べてみたのですが見つからず、、、

最終的に、上記でインストールした @angular/cli を一度アンインストールして angular-cli をインストール しなおすことで対応しました。

npm uninstall -g @angular/cli npm install -g angular-cli

まさか、ツールの名前が変わっていたとは・・・。

angular-cliも ng コマンドを使って雛形を作ります。 試しに使ってみると、angular のバージョンは 2.3.1 でした。

“dependencies”: { “@angular/common”: “^2.3.1”, “@angular/compiler”: “^2.3.1”, “@angular/core”: “^2.3.1”, “@angular/forms”: “^2.3.1”, “@angular/http”: “^2.3.1”, “@angular/platform-browser”: “^2.3.1”, “@angular/platform-browser-dynamic”: “^2.3.1”, “@angular/router”: “^3.3.1”, “core-js”: “^2.4.1”, “rxjs”: “^5.0.1”, “ts-helpers”: “^1.1.1”, “zone.js”: “^0.7.2” },

ふーむ。 つまり、angular2 の雛形用が angular-cli で angular4 の雛形用は、@angular/cli と分かれている、ということなのでしょうか。

でも、ヘルプ等を見ると”angular-cli”って、近いうちに非推奨になるぽいんですよね。

C:> ng help

As a forewarning, we are moving the CLI npm package to “@angular/cli” with the next release, which will only support Node 6.9 and greater. This package will be officially deprecated shortly after.

To disable this warning use “ng set –global warnings.packageDeprecation=false”.

うーむ。

コレを見ると、@angular/cli に移った方が良いのかなぁ。 でも、その場合に angular2 の雛形ってどうやって作るのかな~・・・ わからん。

ご存じの方おられましたら、教えて頂けるとありがたいです。 あークラクラするわー。(適応力低)

コード書いてないのに3時だよ・・・ 寝よ寝よ

オッサン、速聴に期待をかける

私、残念なことに結構な感じで本読むのが遅いのです。

多分、一般の人の半分くらいなんじゃないじゃろか。 もう恥ずかしくて人に言えないレベルですよ。

しかも活字読んでると睡魔が襲ってくるスキルがあるので、普通の人の4倍ほどかけて本読んでる気がします。

学生時代、読書をしなかったバツでしょうか。 社会人になっても、「趣味が小説ですとか、気取りおってからに」などと謎の跳ねっ返りで、読書を敬遠していたバツでしょうか。

悔い改めて本読みます。なので、神様お許しを・・・(´・ω・`)

ということで、年初来から速読の本を何冊か読んでます。 速読の本を遅読で読むので、なかなか読み終わらない悲しさ・・・。

これ、早く脱出したいわー。

が、速読もなかなか難しいもんですね。 すごい勢いで目を動かして単語単位で見るようにして、数ページ進んだところで全く頭に入ってないことに気づいたり。 身につく兆しもありません。トホホ・・・。

速読と一言に言いましても、大きくは2つに分類出来るようです。

一つは、文書を写真のように捉えて読むもの。 もう一つは、処理効率を上げて読むもの。

前者はフォトリーディングが有名です。 マスター出来た暁には、ページを見た瞬間に内容をインプット可能という脅威の性能が特徴です。

インプットした情報は何故か後から記憶として定着するらしく、読んでいる瞬間は理解出来ていないという点もおもしろ特徴です。 ただ、マスターへの道のりは険しいようで、私の周りでもチャレンジした人は多数いましたが、体得出来ている人は一人もいませんでした。 トレーニングも、文字を見ないために焦点をずらしたり、視野を広げてページ全体を見るようにしたりと難易度が高いです。

後者は、、、有名なメソッド名が思い出せませんでしたが、努力で鍛えていくような速読系です。 早口で音読を繰り返したり、目の動きを早くして情報をインプットする速度を上げたりと、通常の読書で発生する作業を個々に効率化を目指します。

こちらも右脳の活用というキーワードは出てくるのですが、フォトリーディングのような捉え方ではなく、文章を読んだそばからイメージ化(映像化)して理解に落とし込むという活用になります。 特に、読書時の脳内音読を止めて一気に映像変換を目指すトレーニングは、いろんな方法でも共通しているように感じました。 こちらは、平たく言ってしまうと「頭の回転が良ければ読むのが早くできる」ということのようです。 ですので、頭の回転がそもそも早い人は、コツを掴んでサクサクっと2~3倍早くなることがあるようです。 すごいな。

身近にも出来ている人が何人かいたりして「あの人のように早く読めるようになりたいな」と目標にしやすい点が良いです。

ただ、私のように元の頭の回転が悪いと、やはり努力が必要で、効果も即効性があるわけではないので辛い修行が続きます。 というか、前述したように「高速で文字を追うだけで読めてない」など、空回り気味です。

筋トレで腹筋を割るにしても、まずは基礎的な筋力やスタミナが必要なように、速読をやるにしても「脳力」を上げておかないとダメなのかもしれません。 能力を上げるために、速読マスターして本を沢山読もうと思ってたんだけどな~・・・

鶏が先か、卵が先か・・・みたいな状況になってきました。

そんなとき、ひょんなことから「速聴」というキーワードを見つけてしまいました。 なんと、音声を数倍速で聞くだけで頭の回転が早くなるというのです。 さらに一説によると、そこから集中力、記憶力、判断力なども玉突きで向上するのだとか・・・。

まぢか。

でも確かに、本読んでてそもそも自分の脳内読む速度が遅いと感じるんですよね。 読むより早い速度で音声が飛び込んできたら、脳が活性化しそうな気も。

ふむーーーー!

もはや人生を完全に折り返したオッサン世代としては、一刻の猶予もありません。 行けそうな方法を見つけたら、やらねばならないのです。(必死) これは、速聴にかけてみるしか・・・!

よしゃーーーー! 明日の通勤から、Audibleで倍速での速聴を試してみるぞ!

育児と筋トレに学ぶ

40歳過ぎて、急に体力の衰えを感じ初め筋トレをはじめました。 ついにメタボ認定もされちゃったしね。(´・ω・`)

どうせやるなら、ちょっとマッチョになりたいですよね。 人生でマッチョになった時期なんて無いですんけど。

マッチョになった暁には、ワシのシックスパッドを披露したいと思います。(´・ω・`)(いらん)

さて、自分のやっている筋トレがマッチョに効果的かどうか、どのように確認すればよいでしょう。 私の中で一つの指標として、「翌日、鍛えた箇所が筋肉痛になっているかどうか」かなと思っております。

筋力を超える負荷をかけることで筋繊維がダメージを受けて筋肉痛となり、再生の際に前回より太くなる。 さらに、筋肉痛が回復したあたりで高負荷をかけると、再生活動中の効果もあり、さらに効率よく再生していける、、、。

と聞いた気がする・・・。(弱

なので、「筋肉痛にならなかった=負荷が足りなかった」と反省するわけです。

でも、なかなか筋肉痛になるほどの負荷ってムズいですよね。 とはいえジムに通う程の月謝は捻出出来ないしなぁ・・・。

育児の楽しみ

話は変わりますが、うちには5歳の子供がおります。

育児というのは、なかなか大変なもので本当に時間を取られます。

どのくらい時間を取られるかというと、「自分も親の時間を相当に奪っていたのだろうなぁ。ふぅむ。たまには実家に電話でもするかな」などと深夜一人で思い巡らしたりしてしまうほど、時間を取られるのであります。

そんな息子との生活で、予想以上に興味深いのが「子供の成長が見られる」ということです。

言葉で書くとありきたりですが、すごいんです。

子供が、どのように運動能力を身に着けていくのか。 どのように言語をマスターしていくのか。 どのように思考が発展していくのか。

走れるようになった! ボールを蹴り返せるようになった! ルールのある遊びが出来るようになった! 悔しい・恥ずかしいとか言うようになった! 時間や距離の概念をマスターしている! 論理的に考えるようになっている! 嘘をつくようになった! 相手が喜ぶか考えて言い訳を言うようになった!

などなど、教えたものからそうでないものまで、本当にいろんなことを習得します。

そして、振り返ると「なんか繰り返しやってたのは、これを練習していたのか?!」と気がつくわけです。

子供って、めっちゃ練習してる。 本を読む、字を書く、時計を見る、数字を数える・・・。

とにかく練習してる。 繰り返しやってる。 公文行って、ひたすら短文を書いたり読んだり頑張ってる。

新しいことを覚えるんだから、脳に相当負荷かかってるんでしょうな〜。 日々、脳の筋トレバリに筋肉痛になってんのかな。

人生の先輩として、多少マッチョになれるよういい感じのトレーナーになってやらんとな〜

学び方を学ぶ

さて、夜な夜な家族に見つからないように筋トレしながら、そんな子供の姿を思い返したりしていると、「新しいことの身につけ方」をふと教えられた気になるわけです。

  • 適切な負荷をかける(筋肉痛ポイントを見極める)
  • 身につくまで繰り返しやる
  • 継続させる

もう今更なことばかりですが、インターネッツが進歩して、膨大な情報にアクセス出来るようになっても、人が何かを学ぶのは「面倒臭がらずに、基本に忠実」が大事ってことかもしれませんな〜。

だってもう子供は、日本語で冗談言えるようになってるもんねぇ。

わし、英語で片言もしゃべれないわ(;´Д`) なんか負けた感が・・・

こ、今年こそ英語が話せるマッチョを目指すぞ! あと関数型言語と、機械学習と、統計と、ろじかるしんんkgt,、、、

40過ぎてもエンジニアを続けるには

40を過ぎてもなお、エンジニアを続けるには何が必要だろうか。

派遣でレガシーシステムの機能拡張や保守の仕事ではなく(※)、自分でシステム構成を考えたり、新しい技術の検証に時間をもらえたり出来る、そんな自由度を持ったエンジニアで居るには。 ※これも大事です。仕事の内容の話ではなく選択の自由との対比という意味です。

技術力だけでは不十分だ。 もし技術力だけで、その評価を勝ち得るには、専門分野で5本の指に入るくらいのレベルが必要だろう。 オープンソースプロダクトの中心的コミッタだったり、まつもとゆきひろさんのように言語を作ってしまうような。 業界の人なら、聞けば知ってるくらいのネームバリューが欲しい。

もちろん、価値は評価する側によっても大きく変わる。 「上記ほどの技術力は我が社にはオーバースペックだ」と感じる会社からは、期待する評価・自由は得られないだろう。

そうではなく技術力を評価しようと思っている会社においても、やはり40を過ぎてくると生半可な技術力程度では管理者(マネージャ)への道を進められる。 右肩上がりになる給与(人件費)に対して、中途半端な技術力では稼ぎにならないからだ。 残念ながら、技術者の単価よりも管理者の単価のほうが高い。 そして仕事において、中途半端な技術力の差は単価に反映されづらいのだ。 その微妙な差が、お客さんの求めるものの成否を分けるなら話は別だけれども。

では40を過ぎてもなお、エンジニアを続けるための方法はなんだろうか。

個人的には、月並みだけれども「技術のアウトプット力」だろうと感じる。

ブログ、勉強会のLT、執筆、さまざまな方法があるが、こうした不特定多数向けにコンスタントに自分の技術をアウトプット出来る力こそが、エンジニアを続けられる唯一の方法ではないだろうか。

社内において、定期的な技術発信で社内の技術力アップに貢献する。 周囲のエンジニアの勉強意欲に良い刺激を与えられている。 社外への発信において、見込み顧客からの問い合わせが入る。 採用募集を出さなくても、優秀なエンジニアが応募してくる。 会社の知名度アップに貢献する。

様々な波及効果により、非エンジニアの人たちにも技術的な凄さを理解してもらうことができる。

「あの人の持っている専門知識は、同業の人達があのように評価するのだから凄いのだな。」と。

そして 「こんな価値あるエンジニアを管理者にしてしまうなんて、もったいない。」 そう周囲に思わせることが出来るのだ。

※管理者という仕事を低く見ているわけではありません。あれは、エンジニアの先のステップではなく全く別スキルが求められる別ジョブだということです。

「あの人には技術のことをして、アウトプットしてもらうのが良いよ」と思ってもらえるのだ。


そんなことを脳内がグルグル回りながら、なぜもっと若い頃からブログを書き、勉強会でLTの一つもしてこなかったのだろうと後悔しているのでありました。 40代からでも、まぁ頑張りますけども。 もはや管理職と二足のわらじ状態からのスタートなんだよなぁ。(´・ω・`)まぢかよ 育児もあるし、時間ないわー

ほんと。若い皆さん。 積極的にブログを書いて、社内勉強会も企画して、覚えたことをアウトプットする練習しといたほうが良いですよ。 そして、そんな活動を評価してくれる会社に出会っておいたほうが良いですよ。

あと英語な。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

やる気クエスト

Kindle Unlimited で面白いマンガを見つけてしまいました。

その名も「やる気クエスト」

やる気クエスト(1) (純コミックス)

やる気クエスト(1) (純コミックス)

※unlimited のリンクじゃないです。すみません。

タイトルでも分かるように、いかにも昨今ありがちな「マンガで分かる系」のビジネススキルを紹介する本です。

しかし! この本は、ただの「マンガで分かる系」ではありません。 本当に説明がマンガだけなのです!

「マンガで分かる系」の本は、確かにストーリー仕立てで学ぶ内容を解説してくれるのですが、大抵マンガの後に必ず文章の解説が出てきます。 入り口をマンガにして敷居を下げているものの、結局活字で理解かい!というハイブリッドさに、どことなく微妙な感じがしてしまうのです。 だって「マンガで分かる」って書いてるのに・・・。

まぁ、ハイブリッドでもマンガ部分で登場人物たちに感情移入して、ストーリーに入り込めれば頭に残るのでありがたいんですけど。 落差がね〜(´・ω・`)

その点、この本は違います。 マンガのみで解説しています!

しかも、その展開や登場人物の行動に違和感が殆ど無い! 「あー、わかる。このやる気のなくなり方分かるわ〜。」と思ってしまうのです。 それでいて、解説内容が薄いかというとそんなことはありません。

確かに活字量に制限があるのですが、そのおかげで逆に「ヤル気コントロール」に必要な要素にコンパクトに纏まっており、要点が記憶に留まりやすくなっている気がします。 イラストこそ上手とは言いづらいものの、とはいえ見づらくなく(初期のパプワくんを思い出したりして・・・)、ストーリーにも引き込まれつつ読み進められるので読み終わった後に、かなり頭に残っています。

とても覚えやすい情報量になっているのです。

いや、これすごいな〜。 自分もこのくらいに要点を整理したドキュメントが書けるようになりたい。

本の内容に関しては、ストーリー内で謎解き的に解説される形式のため あまり書くとネタバレで読む時の楽しみが薄れてしまうのですが、、、 以下の内容は非常に印象的でした。

・ヤル気の量は有限 ・常にヤル気を出してたら人間は死んでしまう。だからヤル気を使いすぎないようにセーブしている ・ヤル気をセーブするタイミング、出るタイミングをマスターすることでヤル気を無駄なく必要なときに使えるようになる。

さて、そのヤル気をコントロールする術とは?!

まだ完結してないマンガなのですが、続きが気になるわ〜

※unlimited のリンクじゃないです。すみません。

やる気クエスト(1) (純コミックス)

やる気クエスト(1) (純コミックス)

やる気クエスト(3) (純コミックス)

やる気クエスト(3) (純コミックス)

やる気クエスト(4) (純コミックス)

やる気クエスト(4) (純コミックス)

やる気クエスト(2) (純コミックス)

やる気クエスト(2) (純コミックス)

ちなみにパプワくんはこちらです。(ヽ´ω`)

大規模プロジェクトの失敗と変化の許容

大規模案件の炎上話は胸が痛みますね・・・ 自分も若いころ「連日終電、月に休みが1〜2日」を数ヶ月という経験をしましたが・・・ここに書いてあることが本当だとすると、想像を絶します。

blog.livedoor.jp

いやー・・・これは・・・

下請けの方々におかれましては、まだ未来もあることと思いますので脱出も視野にいれて良く考えて頂ければと思う次第です。 後ろ指さされたっていいじゃないですか。 心を病んでまでするべき仕事ではありませんからね。 経営者の方は大変でしょうけど・・・。

弊社では、さすがにこんな酷い状況はめったにありません。 普通に休めてますし、帰宅して夕飯食べて子供がネタ後に妻と海外ドラマを観る余裕だってあります。 今夜は、「24 リブ・アナザー・デイ」の最終話みちゃいました。 いやー・・・しかし、あれは・・・

観終わってグッタリしたわー。 だってジャックが、ろ、、おっと。

そんなわけで、責任感とガッツあふれるのに不幸な事故に巻き込まれてしまったIT戦士の皆様。 大企業の失敗を押し付けられて溢れる才能や家族との時間を無駄にしているなんて、もったいないですよ! 弊社では絶賛エンジニアの方を募集しております!普通のライフワークバランスを取り戻しましょう! (謎の宣伝)

それにしても、なぜいい大人が大勢集まるプロジェクトが大失敗してしまうのでしょうか。

企業間の利権のせいでしょうか。 いまだにウォーターフォールだからでしょうか。 多重構造のせいで、1次請けはボンクラなのでしょうか。

いずれも要因としてあるかもしれませんが、最も致命的なのは「ソフトウェア開発は問題の細分化が難しいから」ではないかと思います。

大きな問題に直面した場合、解決のセオリーは「細分化」です。

一般的に、問題が大きくどこから着手していいかわからない場合、行動プランを立てられる程に問題を分割し、優先順位を決めて着手します。 これはソフトウェア開発に限りません。

200人でなわとび100回飛んでください!と言われて、大縄跳びで200人同時に100回飛べるでしょうか? 誰かが縄に掛かっただけで失敗。 回す力が不十分で縄が弛んだら失敗。

こんな仕事、とても不可能でしょう。

でも5人ずつ個別に100回飛ぶのを40組やればOKならどうでしょう。 これなら達成できそうな気がしますね。

しかし、ソフトウェア開発ではこの分割をされることは、ほぼ無いです。

設計・開発は、機能単位に分割して実施しますが、最後に一つにまとめてゴールしようとするのですから一塊に扱っているのと同じです。

「上場企業の基幹システムのリプレース案件」と聞いて何を思うでしょうか。 この業界が長いほど、デスマーチの未来が脳裏をよぎると思います。

でも、こんなスケジュールだとしたらどうでしょう。 最初は「顧客管理」だけ作ってリリース。 その後、「受注」を作って結合してリリース。 一段落したら「在庫管理」を作って結合してリリース。 その後も、「発注」「請求」「経理」と、段階的にリリース。

一気に刷新となると大炎上を覚悟するところですが、上記のように機能単位で開発・リリース出来るなら、なんだか行けそうな気がするぅ〜。(古い)

しかし実際に、上記のように対応することはありません。

なぜなら、後半の開発で設計が変更になった場合、前半につくったアプリまで修正する必要が出てしまうからです。 特に「データ設計」は、後からの変更が非常に面倒くさい。

後で変更が発生したら、ドキュメントも大幅修正。プログラムも大幅修正。 データベースに至っては、テーブル構造から変わるかもしれない。 既存データへパッチを当てないとダメかもしれない。

などなど。 想像すればするほど、うんざりしてしまいます。

「だったら最初から全部考慮しとこうよ。」ということで、全部まとめて整合をとろうとしちゃう。 そして失敗してしまう。

悲惨な歴史の繰り返しなのであります。

しかし。

逆に考えると「単機能開発、後から結合」が実現出来るのであれば、もはや大規模プロジェクトなど恐れる必要はなくなります。 簡単に言えば、個別に作った後くっつけるときにくっつけ方を考えれば良いのですから。

「あー、受注と請求をくっつけるには、請求側に受注データのキー持たせないとですね〜。」 「なるほど、じゃぁ受注データのキー渡せるようにしますね。」 「OK。くっつけられるように次のリリースでカラム追加しておきまーす。」

なんて、気軽に会話出来ればいいわけです!

昨今流行りのアジャイルスクラムも、人にフォーカスしつつ、その根底を支えているのはCIツールや、テスト自動化があってのことと思います。 つまり製品の品質担保を自動化し、大きな変更が発生することを許容することで、ソフトウェアにおける問題の細分化と向きあおうとしているのです。

ここです。ここ。

「変化を許容すること。」

特にデータ構造の変化の許容と品質の担保。 その手法の体系化とツールによる自動化。

これらが可能になれば、ウォーターフォールでも全く問題ありません。 日本のIT再生の鍵はここにありや!(大げさ)

変化を許容せよ!

ん?どこかで聞いたような・・・ 2001年頃流行った、エクストリーム・プログラミングかな?

ケント・ベックは、もうずっと先に行ってたんやな・・・。

いずれにしても、今年後半は「変化を受け入れる」活動に注力していきたいと思います! まずはテスト自動化の確立からっ!

なお、弊社は絶賛エンジニアの方をぼsy(しつこい

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−