デブサミ関西に行ってきました
9月14日(金)、DevelopersSummit2012に行ってきました。
帰り道に、「まだまだ勉強することしかないと実感した」とつぶやきましたが、決して悲観的な意味ではなく、やっぱり未熟な部分は多いんやけど、まだまだ知らないことを知るチャンスがあることが嬉しくて、そういう場所に足を運べたことも嬉しくて、「仕事を楽しむこと」に繋げていけたらなぁという想いでした。
スタッフ、スピーカーのみなさん、貴重な時間をありがとうございました。
(また、快く業務で参加させてくれた上司にも感謝です。)
以下、参加したセッションのまとめ。
■『Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法』 及川 卓也 氏
大規模な開発で重要なことがギュッと詰まったセッションでしたが、それは何も大規模開発だけに言えることではなくて、たとえ小規模な開発であってもそれが出来たら、もっと効率良く価値を届けることに繋がるんだろうなぁと感じました。
＜講演内容メモ＞
【大規模開発で重要なこと】
□工程管理
・どのフェーズで何をするのか、何を持って完了とするのか(doneの定義)を明確にする。
・doneとしていいかをチームメンバで確認してから、次のフェーズへ進む。
□情報共有・目的共有
・チーム人数は少数がベスト(多いと必要以上にMTGが必要になる)。
・チームに分割した時、チーム間での目的を共有することが大事。
→チーム間で目的を共有しないと向かう方向がずれてしまうことは容易に起こりうる。
・プロジェクトのコンセプトは短く覚えられるように表現する。
→原稿用紙何枚も書いたところで、誰もが同じ認識を持てる訳ではない。
→誰もが簡単に共有できないと意味がない。
□ブランチ管理
・少人数なら1つでも問題なく、リリースしてから保守と開発で分けるのはよくあること。
・「check in window」チェックインしていい時間を決めて、毎日定時にbuildする。
□テストとバグ
・「bug bash」「find it」一定のテスト期間を確保する。
→一旦開発をとめて、みんなで叩きまくってバグを見つけるのも大事。
・バグによっては、直さないことも重要。
→他に大きな影響があるものは直さないなど、優先順位を付ける。
□クラウドの特徴
・クラウドにおいて大事なことは、サービスをリリースした後にダウンしないこと。
・初めからユーザの希望に合う完璧さは求めない。
→小規模なものを短期間でリリースして、ユーザの反応を見た上で完成度を上げていく。
□大規模開発と小規模開発の特徴
・少数拠点であれば、厳密なソース管理、ビルド管理が可能。
・世界中、異なる組織から開発に参加すると、ゴールも様々になってしまう。
→開発方針を徹底して共有することが必要。
・Chromeの開発では、コードレビューしていないソースコードをコミットさせない。
□自動化
・開発拠点が異なると、ブランチの管理を人がやるのは不可能。
・テストが通らなければ、コミットできない。テストがないものも、もちろんコミットできない。
→その時点でコミットするものに対してはもちろん、他者がコミットしたことで自分が作ったものが動かなくなることを避ける。
■『Continuous Value Delivery to the NEXT DECADE』 長沢 智治 氏
ウォーターフォール開発、Excelが批判されてるのをよく見聞きしますが……
でも、私はSIerにいながらも、"いかにも"ウォーターフォールな開発をしていないし、(良いか悪いかは別として)ドキュメント類もそこまで重要視されていないという、風変わり(？)なチームにいるために、批判する感覚があんまり分かっていなかったりします。
なので、「なぜ今、ウォーターフォールでは良くない」のかについて、しっくりくるお話が聞けました。
＜講演内容メモ＞
【価値を提供し続ける】
□これからは「Information Technology」ではなく「Business Technology」
・ウォーターフォールモデルは、時間をかけても安全なものを届ける開発方法。しかし、ユーザの要求は変化するものであるため、BusinessとTechnologyが同時に成長しなければならない。(今までは、ビジネスに「ITがあれば便利」程度の要求だったのに対して、今は「ITが不可欠」になっている。)
・それを防ぐために、定期的に小さな単位で価値を届けることを考える。
・ユーザの価値は固まっているため、ビジネス価値は固定された状態でスタートする。それ故に、時間を書ける程、投資対効果は低くなる。
→投資対効果を高くできる短い間隔で、その時々で必要な機能だけを提供する。
・仕掛りが長いと、各々がI'm done.で仕事を終わらせた時に、基準がバラバラになり、完成したときに思ったものと違うものができていることがありうる。
□アジャイルプラクティスの実践
・フィードバックを得る機会が少ないと、開発者は自分勝手な魔法を使いがち。
・継続的に価値を届けるためには、「リリースした後は知らない」ではダメ。
・実装、テスト、リリース、フィードバックを繰り返し、ビジネス価値を考える。
・ユーザのフィードバックを得て、顧客とのやり取りによって、次のイテレーションで実装可能な機能を明確に決める。
□開発者に求められるもの
・常に進化する意識をもつこと
・利用者の視点で見ること
・技術と相乗りする勇気
・これらは、持続可能なペースで継続することが重要。
(新しい習慣を身につけるためには、中学生は3ヶ月、大学生は半年、大人は一年かかる。)
・開発だけではなくて、価値を届けるための流れを意識する。
■『エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方』 鈴木 雄介 氏
ウォーターフォールとアジャイル、各々の特徴と、どんなプロジェクトにどんな開発方法が効果的なのかであったり、開発方法にこだわっても意味がないというお話で、「頭を使ってしっかり考えること」が大事ということを再認識させられました。
＜講演内容メモ＞
【エンタープライズ開発の現状】
□エンタープライズ開発は、より複雑で不確定なものになっている。
・ステークホルダーの多様化、不確定要素の増加などが原因。
・IT化によって、顧客が技術に詳しくない場合もあり、認識のブレから成果物にもブレが起こってしまう。
→ウォーターフォールの限界。
・イテレーションなタイムボックスによるマネジメント。
・動くソフトウェアを作った上で、フィードバックを得る。
→仕様の決まっていないことを一旦おいておけるという利点。
・全体感の事前共有ができている必要がある。
【最適なプロセス】
□どんな開発プロセスでも「作業の管理」と「コミュニケーションの管理」が必要
・「作業の管理」「コミュニケーションの管理」には、対象物によって最適なモノ、方法を選ぶべき。また、必要ないモノは必要ないと宣言すべき。
・プロセスは道具でしかないので、何を管理したいのかを考えることが大事。その上で、対象に合わせて方法を選ぶ。
■『ブラウザテストを自動化することにした ～TestNGとSeleniumでやってみる～』 阪田 浩一 氏
今の自分の仕事に活かせる、取り入れられたらいいなぁと思っているトピックだったので、デモを交えた実践方法が聞けて、とても有意義でした。「これ取り入れてみましょうよ！」というために、まずは自分でやってみることから始めます。
(実践的な内容やったから、メモ少ない…)
＜講演内容メモ＞
【ブラウザでのテスト自動化】
・「Selenium IDE」Firefoxアドオンでブラウザでの操作を記録する。
・「Selenium WebDriver」ブラウザでの操作をコーディングする。
・「Selenium Grid」複数ブラウザでのテストを複数マシンで並列実行する。
□Selenium WebDriver
・ブラウザの種類を選ぶことが可能(IEとChromeは設定が必要)。
・実際の画面遷移に沿って、画面遷移ごとの処理時間を設定可能。
・ファイルのアップロード、javascriptのアラート、ダイアログなどの制御も可能。
・エビデンスとして、スクリーンショットを撮ることも可能。
→JUnit、testNGなどでテストコードを書いて、ブラウザテストも自動化。
■『Struts の時代から、標準 Java EE で実現する効率的な Web サイト構築の時代へ』 寺田 佳央 氏
「strutsにこれ以上の発展はない」らしい。
会社に入って1年半、ずっと同じチームにいてstruts2しか使ったことのない自分にとっては、今の開発環境に慣れてしまって、それが普通という感覚ができつつあったりします。だから、「使いにくい」とか「設定が面倒」とかっていう感覚もそこまでなかったりします。(チームに入った時にはすでに保守開発やったから、開発環境は整ってたこと、フレームワークなにそれ状態からのスタートなために、むしろ便利だと思ってたこととかが基点かなぁと思いますが…)
寺田さんのお話もデモも流暢すぎて、若干ついていけてませんでした。。
でも、すごく興味深くて、自分でもやってみたくなったので、家に帰ってすぐNetBeansをインストールして、デモを再現しようとしてみました！が、同じDBを利用できなかったので、他のを選んで適宜修正しながらやってみたら動かなかった。。動画を止めながらやってみてたけど、寺田さんのブログの詳細見ながら、もう１回やってみようと思います。上手く行ったら、何か作ってみようかな。。
＜講演内容メモ＞
□JavaEE、JSF2.0(JavaServer Faces)を使ってみる
・NetBeansをダウンロードするだけで、apache、tomcatなどの設定が必要ない。
・viewはfacelets(xhtml)
・コンポーネントベース
・htmlと一対一で対応するJSFのタグが存在する。
・国際化対応もロケールごとのpropertiesファイルを作成して、ロケールを指定するだけで可能。
・画面遷移のxmlは不要。xhtmlでActionのメソッドを直接指定可能。
■『あの人の自分戦略を聞きたい！－デブサミ関西編』
□前川 直也 氏
■自分のエンドロールをどう描くか
・エンドロールに名前を残す。
→「人間としての自己の存在を自覚し、生きてきたことの証を残して生涯を終われ」
・人生の分かれ道
→変化を抱擁せよ。
・SNSは人から認めてもらうことのacknowledgment。
→試行錯誤⇒人に認められる⇒次への原動力
・自分には何ができるか、他の人と何が違うのか。
→吸い取る⇒考える⇒伝える⇒つなげる⇒描く
・自分自身を信じることも大事。
□野崎 啓史 氏
■プログラマであり続けるために
1. がんばらないこと
・がんばる＝無理すること
→無理したら続かない
・継続は絶対的な力。
2. 選択する
・選択しないことも選択。
・迷ったことはする。
→迷う＝やりたいこと
3. 年齢を気にしない
・若くても20年そこら積み重ねてきたことがある。
・自分の歳から考えて、残り時間がないと思わないため。
→新しいことを始めるのに、枷は少ない方がいい。
■ありたいプログラマ像
・ジョーカー
→エースではなく、広く浅く
・三人目
→思いつくのは一人でもできる。始めるのは二人いれば出来る。でも、続けて広めていくには三人目が必要。
■何かを始めるには障害があるもの
・すべての障害がなくなったとき、自分はどう振る舞うか。
□中村 洋 氏
■自分の源泉
・チームの成長
→自分だけでなく、周囲の成長
→成長出来る環境を整える。
・お土産
→次会ったときにお土産を渡したい。
→成長した姿を見せる。
・恐れ
→素晴らしいコードを書けるわけではないし、1人でリリースもできない。
■自分戦略
・自分でハンドルを握る。
□表明
→やりたいことは表明する。黙っててやりたいことが入ってくるわけがない。
□準備
→いざやりたいことが舞い込んできたときのために、やりたいことをやるための準備をしておく。
□雪かき
→他の人がやりたがらないことを積極的にやる。それは、信頼貯金になるし、待ってたボールが飛んでくることに繋がるかもしれない。
□巻き込む
→一人だとできなかったことでも、二人ならできるかもしれない。
・「仕事なんて楽しくないやんか」(昔の上司に言われた言葉)
→楽しく仕事をするために自分ができることにベストを尽くす。
3人の方の自分戦略は、それぞれ全然違うんやけど、自分の想いというか信念というか、そんな気持ちをもって行動してきてはることが見えて、自分が大事にしてることってなんやろう…と、考えるきっかけになりました。
特に、irofさんの「がんばらないこと」と「年齢を気にしない」という話には、自己否定しがちな自分にとって、自分を肯定するための勇気をもらえた気がします。
まとめを書いてて思ったけど、前川さんの「自分には何ができるか、他の人と何が違うか」という話も繋がってくるし、「他の人と違う、自分にしかできないこと」を考えることは、中村さんの自分戦略とも繋がってくるなぁと。。
今の自分は、すごく恵まれた環境にいることは間違いなくて、でもきっとそれを活かしきれてなくて、もったいないことをしてるような気がしないでもない。
自分に足りないことは見えてきてもいるし、少しずつでももうちょっと積極的に。。。
懇親会では、スピーカーの寺田さん、阪田さん、irofさんとお話させていただいたり、社内読書会でテレビ越しにしかお話したことのなかった先輩にも相手してもらったり、自分戦略の前川さんにもお声掛けさせてもらって少しお話できたり…と、とても楽しくて有意義な時間を過ごすことができました。ありがとうございました！
【社内勉強会】第４回WUM
昨日、第4回ウォームアップミーティングに参加してきました。
お客さんとの打ち合わせでまた行かれへん…と思ってたら、
当日になって急遽打ち合わせが中止になったので、
第1回に参加させてもらって以来、やっと2回目参加することができました。
今回は、SQLチューニングのお話でした。
ちょうど業務で、SQLの性能も意識して実装しないといけないことが
見えてきてたタイミングだったこともあり、すごく勉強になったので備忘録。
■SQLチューニング
システム開発でパフォーマンス問題の原因となることは何か？
大きくは、以下の3つだそう。
1. SQL
インデックスが利用されていなかったり、JOINが多すぎたり、
そもそも大量のデータを返していたり、、、
2. HTML (JavaScriptなどのフロント部分)
入力項目が多いと重くなることや、JavaScriptを読む間はブラウザの描画が
止まるために、最初から使わないものを最初にincludeしてしまうことで、
表示されるまでの体感速度が遅くなったり、、、
3. Java (主にbatch)
(…メモがない(*_*)
今回は、この中でも1. SQLを中心にお話してくださいました。
□チューニング方法
SQLにも、同一の処理に対して複数の記述方法があるけど、
「正しい結果を得ること」ばかりを意識してしまい、パフォーマンスに
ついては考慮されていなかったりする。
「動けばいい」ではなくて「使えるもの」を作らないと意味がないのに。
そこで、大きく2つのチューニング方法のご紹介！
★定型的なSQLチューニング
これは、開発チームでコーディングルール的なものを決めておくというもの。
SQLの組み立て方と言うよりは、書き方のルール(大文字小文字の
使い分けとか…)が中心だったと思うけど、開発者のスキルに依存しないで、
一定の品質を保つためにはこれも重要。
後は、簡単に意識できることだと(とある『書いてはいけないSQL』の
中から紹介)、
・SELECT * を使わない
必要な項目だけ指定して取得する
・WHERE句の左辺に関数を使わない
インデックスが使えなくなるため、パフォーマンスが下がる
・日付の比較のように a が b<a<c となることを条件に書く場合は
BETWEENを使うこと
これ、b<a and a<c って書いてるわーと、言われて初めて気付いた…
・GROUP BY する項目にインデックスを貼るのは基本
基本なのに、意識したことなかった…
★非定型的なSQLチューニング
自動生成される実行計画でも、適切かを調査することも大事。
特に、朝と夜では取得するデータ量が大きく異る場合などは統計情報を
取るタイミングを意識しないといけない。
というお話やったんやけど、Oracleに特化した話なのか、、、
MySQLとPostgreSQLしかまとも触ったことなくて、イメージが湧かず。。
最初からきれいにパフォーマンスの高いSQLを書くのは難しいこともある
SQLも1回書いて「よし、動く！」で終わりじゃなくて、リファクタリング
して、効率よく、保守性も高いSQLにしていくべきだと実感。
また、SQLの性能低下の原因となるのは、外部設計の時点で既に問題に
なっている場合が多いそう。そういう状況を防ぐためにも、
上流工程から性能問題を「予防する」という意識を持つことも大事。
□とはいえ、場合によって使い分けることが一番大事
「SELECT * は使わない」ということについて気になったので質問しました。
欲しい項目が少し異なる場合、似たようなメソッドを複数作ってしまうと
いう状況が有り得ると思うんですが、それでも「*」は使わないべきなのか、
保守性も考えて似たようなメソッドを乱立させるべきでないのか。
というようなことを、まとまらないまま話しました。。。
もちろん、似たようなメソッドが乱立する状況はよくなくて、
解決策としては、取得したい項目を引数として渡すことで極力「*」は
使わないようにできるとの解答をいただきました。
でも、ORマッピングなんかは「*」で取ってくるけど、それも良くないの？
と思って質問したら、生産性上がるからぜひ使ってくださいとの
解答をいただきました。
これでは、どうしていいのか分からない…(*_*)
でも、「*」をつかうことでパフォーマンスが低下するのは一部の話で
あって、データ量や書いてるSQLにもよるのはもちろんなので、
パフォーマンスを意識して使い分けられることが重要という結論に至りました。
感覚的なものもあるので慣れることも重要だとか。
■LTを聞いて思ったこと
□まだまだ出会ってない素敵な先輩がいっぱいいる
1人目は、4年目の女性の先輩が話してくれはったんやけど、
すごく高い意識を持って勉強会などなどの活動を積極的にしてはることを知った。
2人目も女性の先輩で、ワーキングマザーのライフワークバランスについてのお話。
残念ながら、まだまだ予定はないけど、子育てと仕事を両立させることについて
どっちも100%はムリやから、周りに甘えることも大事っていうことは
しっかり覚えとこうと思った。
自分が絶対どっちも100%を目指そうとする性格なのはよく分かってるし。。
LTしてくれはった先輩方とも、SQLチューニングについて話してくれはった
先輩とも直接話してみたかったけど、懇親会参加せずに帰っちゃったので、
いつか話せる機会があれば嬉しいなと思いながら、、まとめ終わり。
【勉強会】アジャイルサムライ関西 他流試合
6月30日(土)、"初"社外勉強会となる『アジャイルサムライ関西 他流試合』に参加してきました！
毎週参加してる読書会の皆さまと、京都道場、大阪道場、他社の道場(名前だしていいか分かんないので…)の方々が20人ぐらい集まりました。
内容は3つのワークショップとディスカッション。
ワークショップって、何かこう…就活時の「ちょっと胡散臭い積極性アピール合戦」なイメージやったけど(っていっても、ワークショップがあるような説明会とか面接にはほぼ参加せんかったけど…)めっちゃ楽しかったです。
でも、楽しいだけで終わってしまうと、ただ遊びに行ったみたいになってしまうので、振り返りを。
■ワークショップ1＜紙飛行機＞
チームで紙飛行機を作って3m以上飛ばせばok！なワークショップ。
条件が幾つかあって、なかなかスムーズには行きませんでした。。。
でも、イテレーションを重ねるごとに、作業の仕方云々を改善できて、
最初は3mに達したのが0機やったのが、5回目には6機飛ばすことができました！
イテレーション毎に、何が悪かったか、どうすれば良くなるかを振り返って、改善するの繰り返し。
実際の仕事現場で「チームみんなで計画を立てて、振り返る」っていうのを全く経験したことのない私にとっては、改善できる過程を実感することができたのは大きな収穫でした。
■ワークショップ2＜レシート＞
参加者全員が食べてきたお昼ごはんのレシートを価値のある順に並べるワークショップ。
ひとまず、値段順にレシートを並べて、全員で話しながら価値のある順に並び替えます。でも、結局「何を基準にするの？」が定義できなくて、定量的に判断するにはやっぱり値段という感じになり、最終的な結果もほぼ値段順でした。
そこで、、、何を持って価値があるとするのか、どうすれば全員が納得できる形で価値のある順に並べることが出来るかをチームごとにディスカッションしました。
味とか値段・量、食べた状況とか、食べログの評価とか、基準とする項目を決めておいたりとか、持ち点を決めておいて各々が点数付けするとかが上がってたと思います。たしか。。。
ゴールが共有できてないことで、間違った方向に進んでしまう状況って簡単に起こり得るんだろうなぁ、と思ったりしました。
■ディスカッション1＜どんな状態がアジャイルと思うか＞
・チームが自己組織化している
・積極的な行動で待ちがない
・ゴールが共有できている
などなど、割りと教科書的というか、何となく「分かる分かる」という感じでディスカッションをした後に、、、じゃあ「バスに乗りたがらない人を乗せるには？」という問いが。
この問いは結構難しかったです。
「乗せる」ていうと、どうしても会社の上下関係で考えてしまって、「2年目がリーダーさんを引き込んで」っていう状況が想像できないというか。。
でも、みなさんの答えを見てるとそんなに難しく考えなくてもいいのかなっていう気もしたので、2年目やからこそ「チームに新しい風を」じゃないけど、自分が考えてること、やってみたいこととかを、もう少し積極的にコミュニケーション取って、伝えていけばいいのかなと思いました。
■ワークショップ3＜マシュマロチャレンジ＞
パスタとテープと紐でタワーを作って、マシュマロを乗っければok！なワークショップ。これ、めーっちゃ楽しかった！
1回目は、何となくこうしたらいいんちゃう？ぐらいな感じで作り始めて、こまめにリリース(高さ計測！)して、最終的には5チーム中1位でした♪
2回目は、もっとしっかり計画を立ててトライ。2回目も、念のため低い高さの段階で1回リリースして、このときも最終的には5チーム中1位でした♪♪
それから迎えた3回目。2回目は割りと計画通りに進んだんやけど、振り返って辿り着いたのが「この方法やと、2回目の高さが限界」っていうこと。
なので(?)、3回目はチャレンジに走ってしまって、こまめなリリースをすることもなく0mで終わりました。
高さは低くても、形のあるものを提供できる(実務において言えば、提供できる機能は少なくても、動くものが提供できる)っていいなぁと実感しました。
お客さんもハッピーやし、作ってる自分だって絶対楽しいし。
■ディスカッション2
4人のマスター先生が質問に答えてくれるコーナーでした。
話の中で、何より今必要なことってこれかもと思ったのは、「上司からの信頼感」を得ることでした。1ヶ月黙って好きなようにさせてもらえるぐらいの信頼感。
そういうのは、やっぱりまだ2年目ペーペーには力がない気がするのです。でも、仕事内容的には同じ事をしていても、目に見える形で示すかどうかでだいぶ違うと思うのです。と思ったので、まずは「ひとりかんばん始めます」と最後に付箋に書いて、地味に"宣言"してきました。
他にも色々お話があったけど、ちょっと自分のコンテキストとは離れてる感じがして…というか、ここまで結構お腹いっぱいな内容で、これ以上消化しきれませんでした。。
懇親会でも色んな方々とお話できてとっても楽しかったです。
その中で、マシュマロチャレンジで同じチームだった方に、「手先の器用さ」と「残り時間の少ない中でも焦りのない集中力」をもってるって、褒めてもらいました。(ありがとうございます！)
そんな風にフィードバックできる人ってすごいなぁといつも思います。
という訳でまとめ。
今回の目的は「社外のコミュニティに参加してみること」だったのですが、今「また色んな勉強会参加してみたい！」と思えてるので、十分に目的達成です。
とはいえ、自分の気付きとして得たことはやっぱり活かしていきたいので、できることから始めてみます。あー、お腹いっぱい。
【社内勉強会】ウォームアップミーティング
毎週木曜日、朝の読書会でお世話になっている @yohhatu さんにお誘いいただいて、他部門の勉強会に参加してきました！
終わったら、社内SNSにOutputすること！っていうお話があったんやけど、他部門だとコメントつけられないとも聞いたので、自分のブログでOutputします。
■Xenlonとは
Xenlonは、弊社で独自開発しているJavaのフレームワークなんですが、、、
「名前は聞いたことあるけど、どんなものか全く知らない」状態でした。
（1年前は名前すら知らなくて、リーダーさんに「研修からやり直してこい」と言われ、激落ち込み(;´д｀)したこともありました。。。）
そんな訳で、簡単にまとめ。
□Xenlonの特徴
・SAStrutsに弊社が手掛けるシステムでよく使う機能をアドオン
・Xenlonの上に業務アプリケーションが乗っかるのではなく、
間にプロジェクトのフレームワークを挟んで使う
・フレームワークなだけでなく、生産性向上にも使える
→テストの自動化とか、エビデンス作成の自動化とか
□Xenlonの役割
・開発基盤の共有、資産化
→機械的なコーディングより、生産的なロジックに注力できるように。
話を聞きながら意識していたのは、「Xenlonと他のフレームワークとの違い、Xenlonがより優れているところは？」という点でした。
私自身が感じたのは、ただJavaのフレームワークなだけでなくて、生産性向上のツールとしても使えるところが優れているのかなということ。
自分のイメージでは、その2つって別々に用意しないといけないと思ってたので、、、と言いながら、うちのチームが使ってるstruts2に入ってるJUnitも一応自動化やんか。。。
で、この点に関しては質問して、
・弊社の現場でよく使ってる、必要としていることに対応していけること
・現場の声が届きやすいためスピード感がある
という答えをいただけました。
■大事にしたいこと
□将来の自分のための生産性向上
今まで自分の中では、「生産性向上」っていうとやっぱり「お客様のため」と思っていました。でも、それだけじゃなくて、「自分のため」でもあるっていうことがとってもココロに響きました。
この世界ではやっぱり技術力が重要で、限られた時間の中で、技術力を得ようと思うと、残業しないで自分の時間を作ることが必要。そのためには、生産性を向上させて残業しない！これは、ぜひ大事にしていきたいと思います。
□周りへの展開、Output
「改善すること」についてのLTで、めんどくさいと思うことを自動化しようっていうお話がありました。で、いいこと、いい方法がないかを調べてみたり、周りの人に聞いてみるっていうことはもちろんなんやけど、そこで知り得たことを「周りに展開しよう」っていうことを聞きました。
私自身は、周りに展開するって「結構勇気がいる」って思ってたんけど、知ってたら「そうやんねー」で終わる話なだけやし、知らんかったら「そうなんやー」って聞いてくれるし、別に「そんなん知ってるし」って思う人はいないよって聞いて、ちょっとハードルが下がりました。どんどんOutputしていこうと思います！
□時間は作るもの
これは、最近特に思っていること。平日はどうしても、毎日少しずつしか時間がとれなくて、時間が足りない！って思うこともあるけど、「少しずつでも量は質に転化する」っていう言葉を聞いて、自分がやってることにほんのちょっと自信がもてました。いつか遠くない未来に「ByName」で声がかかる日を待ちわびて、一歩一歩を積み重ねていきます！
今回の勉強会、誘ってもらったときは、お客様との打ち合わせがあるから絶対いけないやーっていう状況やったんやけど、ラッキーなことに打ち合わせ時間が早まって参加することができました。
元々人見知りな性格なので、他部門の知らない人たちの中に一人で乗り込むなんて、普通に考えたら絶対無理なんやけど、自分の「興味」と、誘ってくださった @yohhatu さんもいはるんやしと思えば、社外常駐からの大阪本社他部門への乗り込みもなんのそのでした。
懇親会まで参加して、はじめましてな先輩方ばっかりやったのに、色んなお話を聞くことができて、とも有意義な時間を過ごすことができました！
Groovy-Eclipse Pluginのインストール
開発環境作りの二歩目として、eclipseでgroovyの開発ができるように
Groovy-Eclipse Pluginをインストールしてみました。
■Pluginインストール
1. Groovy - Eclipse Pluginを参考にインストールするプラグインのURLを確認
※eclipseのバージョンと同じものを利用する
＜eclipseのバージョン確認方法＞ ・[ヘルプ]→[Eclipseについて]をクリック ・インストールされているプラグインの一覧が表示されるので、 Eclipse.orgのアイコンをクリック ・項目が複数表示されたら、「フィーチャー名」が 「Eclipse プラットフォーム」となっているのを確認 →これがEclipseのバージョン
2. [ヘルプ]→[新規ソフトウェアのインストール]をクリック
3. [追加]→「ロケーション」に1.で確認したURLを入力
4. 選択肢の内容をすべて選択→[次へ]
※バージョン3.5の場合は、「Groovy Eclipse SDK」と「Groovy-Eclipse」のみしか
選択肢はないので全部選択する
5. 同意が必要な項目があれば確認されるので、同意してインストール開始
6. インストールが完了したらeclipseを再起動
7. [ウィンドウ]→[設定]を確認して、Groovyの項目が追加されていれば
インストール成功！！
■Groovyプロジェクト作成
1. [新規]→[その他]をクリック
2. [Groovy]→[Groovy Project]→[次へ]をクリック
3. 「プロジェクト名」を入力して[完了]をクリックして、プロジェクトを作成
4. 作成したプロジェクトのsrcフォルダを右クリックして、
[新規]→[Groovy]→[Groovy Class]→[次へ]をクリック
5. 「クラス名」を入力して[完了]をクリックして、クラスファイルを作成
6. Javaのクラスファイルと同様に、
class クラス名 {
}
と、自動的に生成されてしまうので、一旦全消し
7. 動作確認のために、下記のような適当なソースを記述して保存
println "Hello Groovy!"
8. クラスファイル上で右クリック→[実行]→[Groovy Script]をクリック
9. コンソールに「Hello Groovy!」が出力される
■Javaプロジェクト作成からのGroovyプロジェクトへの変更
1. [新規]→[Javaプロジェクト]をクリック
2. 「プロジェクト名」を入力して[完了]をクリックして、プロジェクトを作成
3. 作成したプロジェクトを右クリックして、
[構成]→[Convert to Groovy Project]をクリック
4. プロジェクトにGroovy Librariesが追加され、
自動的にGroovyプロジェクトに変更される
※クラス作成以降の動作確認は、「Groovyプロジェクト作成」と同様
switch文でStringを使う
Javaのswitch文で、caseにString型の値を指定しようと思うとちょっと面倒臭い。
Enum型のオブジェクトを用意して、その中でString型の値を列挙しておく。
新たなデータを増やしたい場合は、Enum型のオブジェクトへの追加と、
caseの追加が必要になる。
※JavaSE7からは、String型も指定できるようになってるはず。
例えば、都道府県ごとに処理したい場合はこんな感じ。
enum Prefecture { Kyoto, Tokyo, Osaka } public class EnumPref { public static String getPref(Prefecture pref) { String result = ""; switch(pref) { case Kyoto: result = "京都"; break; case Tokyo: result = "東京"; break; case Osaka: result = "大阪"; break; default: result = "それ以外だよ！"; } return result; } }
うん、やっぱり面倒。
これと同じ処理をGroovyで書いてみるとこんな感じ。
def result
def pref = "Tokyo"
switch(pref) {
case "Kyoto" : result = "京都"; break
case "Tokyo" : result = "東京"; break
case "Osaka" : result = "大阪"; break
default : result = "それ以外だよ！"
}
Groovy始めました。
と言っても、まだインストールしただけぐらいなものですが。
とりあえず、インストール手順の備忘録。
・インストール
1. 公式サイトにあるダウンロードページにアクセス。
http://groovy.codehaus.org/Download
※今は、version1.8が安定版らしい。
2. 「Downloda Windows-Installer」の「Binary release」をクリックして、
インストーラをダウンロード。
3. 後は、「next」をクリックしていくだけで、Pathの設定までしてくれるので、
自分では何も設定することなく完了！
※おそらく、環境変数「JAVA_HOME」にPathが設定されていることが前提。
4. コマンドから「groovy -v」を実行して、インストールしたGroovyの
バージョンが返ってきたらインストール成功。
Pathの設定は勝手にやってくれるはずなんやけど、
なぜかうまくいかなかったので、自分で設定し直しました。
でも、結局は設定内容は何ら変わらずなので、何がダメやったのかはなぞのまま。。。
