コンパイルエラー「\65279は不正な文字です。」
Eclipse上で問題なく動いていたJavaコードに対して、コマンドラインからビルドをかけたところ表題のエラーが発生した。
\65279 = UTF-8のBOM(Byte Order Mark)
どうやらソースファイルの中に、エンコードUTF-8でBOMありのものが紛れ込んでいるらしい。
Windows機を使用していたので、手っ取り早い対処法にて対応した。
【対処方法】
1. サクラエディタで対象ファイルを開く
2. 名前をつけて保存を選択
3. 文字コードセット、改行コードの右側のBOMチェックをOFFにする
4. 保存する(上書き)
【Eclipseでエラーにならなかったのに、なんでjavacだとエラーになるの？】
EclipseではJDTコンパイラを使用していて、コマンドラインではOracle純正コンパイラを使用していることが原因。
マシンの環境パスで指定するjava.exeは、普通はOracle公式サイトから落とした純正のものを利用する。コマンドラインでコンパイルする時はこれが使われる。
一方で、Eclipseでコンパイルする時には、Eclipseの中のjava.exeが使われる。このjava.exeはEclipse独自のもの。
そして重要な事は、
eclipseコンパイラは純正コンパイラよりもコンパイルエラーとする条件が緩い。
ということ。
調べてみるとこんなのがあった。
JDTコンパイラならOKだけど、純正コンパイラじゃ通らない記述
http://d.hatena.ne.jp/eyamane/20061212/1165892799
ECJ (Eclipse Compiler for Java) は面倒見が良すぎ…
http://d.hatena.ne.jp/imatake/20100702/1278038592
知っていればたいしたことないけど、知らないとハマる罠。
オマケ
JDT(Java Development Tools)の概要
なぜ Eclipse は JRE を使っているのにコンパイルできるの？
http://www.hitachi.co.jp/Prod/comp/soft1/cosminexus/useful/tips/090606_eclipse-jre-compile.html
継続的Webサービス改善ガイド 第2章
継続的Webサービス改善ガイド
第2章 開発環境の改善～技術的負債の返済と，レガシーコードの仕様化テスト
http://gihyo.jp/dev/feature/01/webservice-guide/0002
【概要】
webサービスの成長とともに大きくなる「技術的負債」を返済するために、
筆者が所属する会社で取り組んでいる方法について紹介されている。
以下、1ページ目、および2ページ目前半の内容要約を記載する。
■技術的負債
アプリケーション層とハードウェア層、それぞれに存在するが、
ここではアプリケーション層の技術的負債を対象とする。
具体的には、
・障害対応のためにテストを書かずにその場しのぎで入れたコード
・「TODO: あとで直す」といったコメント付きのコード
・とりあえず動くことを目的とした適当な設計のコード
・コピペコード
・脆弱性が存在するライブラリを使用しているコード
など。
もちろん、障害発生時は「奇麗なコードを時間をかけて書く」よりも
「汚くてもとりあえず動くコード」を書くことが求められるが、
その「汚いコード」を放っておくと、
・システムの複雑性が増すことによるリリースサイクルの長期化
・システム障害の発生や長期化
などの問題に繋がってしまう。
そしてこの「汚いコード」は、エラーで処理が止まるわけではないので、
改善に着手されにくい。
■継続的な現場改善
技術的負債の蓄積 ▶︎ サービスの負債
では、技術的負債を抑えるためには何が出来るか？
・毎日の作業の一環に組み込む
毎朝30分間、技術的負債の返済を行うための時間を確保する。
ここでテストが無いコードにテストを書いたり、リファクタリングを行う。
・CIの導入
Jenkins, Travis CI, Coveralls, Gemnasiumなどのツール、サービスを用いて、
自動的にテストの実行、失敗の検知といった作業を自動化する。
・コードレビュー
チーム内コミュニケーションを促し、結果としてコードの品質向上や
不具合の検出が期待できる。
全てのコードは、書いた本人以外によるコードレビューを通すべき。
GitHub(無償でもEnterpriseでも)のpull requestを用いたレビューにて、
書いた本人が気づかない点に気づけるしくみを作っている。
■開発環境の改善
技術的負債の返済には、環境に問題がある場合もある。
例えば、
・本番環境で動いているコードの中に、バージョン管理されていないものがある
・テスト環境、ステージング環境が存在しない
・開発を行う環境が物理サーバ、仮想サーバ上にしか存在せず、
開発者個人のマシンで確認できない
といった場合は、技術的負債を返すためのコード変更が行いにくいと言える。
バージョン管理
サービスを運用していると、
・サーバ上でコードや設定ファイルを直接編集して対応
・メンテナンススクリプトをサーバ上で作成して実行
といったことが発生する。
これらもすべてバージョン管理システムに保存する必要がある。
Railsのようにデータベースのマイグレーションスクリプトがフレームワークに
内包されていれば、意識せずに上記バージョン管理が行われている。
そうでない場合は、少なくともデータベースに発行するSQLは
すべてバージョン管理しておくべき。
開発環境の仮想化
サーバ設定作業の自動化 ▶︎ Puppet, Chef
本番環境を気軽・高速に開発環境として再現できることは重要。
■レガシーコードの継続的な改善
『レガシーコード改善ガイド』による言葉の定義
テストがないコードはレガシーコード
1時間前に書いたコードもレガシーコード？
▶︎ テストが無いとリファクタリングできないので遅かれ早かれそうなる。
レガシーコードを改善するためには？
▶︎ 仕様化テストがオススメ
既にあるプロダクトコードの挙動が仕様であるとして書くテスト。
リリース済みのサービスは、仕様の変更は慎重に行う必要がある。
【感想】
開発の現場では「動いているコードは触るな」という言葉が度々叫ばれる。
例えそれが汚いコードであっても、デグレを恐れて改修しないことは多々ある。
一方で、TDD実践者として有名な@t_wada氏が言うように、
「動いているコードだからと言って触らなければ、そのコードは死んでしまう」
というのは、まさにこの技術的負債のことだろう。
つまり、改修する/しないの決定は状況に応じて判断する必要がある。
直近を平和に収めるためには「動いているコードは触らない」
例えば「3ヶ月後にサービスの終了が決まっている」といった場合であれば、
敢えて危険を冒す必要はないだろう。
未来の安寧を求めるならば「積極的リファクタリング」
企業の基幹システムで長期間の使用が予測される場合であれば、
技術的負債を抱えたまま運用をすることは考えたくない。
リファクタリングしやすい環境づくりは急務と言える。
もちろんこれらの作業には多大な工数がかかり、
顧客から見たらコストの増大に他ならないが、
最終的なコストを考えると事前に手をうっておいた方が良いことも多いだろう。
※個人的には最終的なコストが例え安く収まらないとしても、
※必要経費としてこれらの導入は行うべきだと考える。
最後に、テストコードについて少しだけ言及する。
テストコードは、ただ書けば良いというものではないと思っている。
現場で「使えないテストコード」を見かける事が多いが、
これらは二重メンテになるため邪魔な存在でしかないからだ。
使えないテストコード
・メンテされていなくて動かない
・データ依存で、データが少し変わると動かない
・クラスを呼ぶだけ(1パターンしかない)
※もちろん呼ぶだけでテスト出来るクラスもあるのでそれは例外とする
使えるテストコード
・可読性が高くメンテしやすい
・再利用性が高い(データが変わっても動く)
・パターンが網羅されている
かく言う自分も、気づけば使えないテストコードを書いていることがある。
実践はなかなか難しい。
リファクタリング未遂事件
※別に事件でもなんでもないのだけれど語呂が良いので。
こんなソースコードを見かけた。
変数a, b, c, d, hoge, fuga, hogehoge, fugafugaは全てString型。
1. if (null == hoge || null == fuga) {
2. if(a.equals(b) && c.equals(d)) {
3. // 処理A
4. }
5. } else {
6. if(a.equals(b) && c.equals(d)
&& hoge.equals(hogehoge)
&& fuga.equals(fugafuga)) {
7. // 処理A
8. }
9. }
やってることは、
比較対象変数同士が等しい場合に「処理A」を実施する。
hoge, fuga, hogehoge, fugafugaにはnullまたは空文字列が入る可能性があり、
少なくともどちらか片方にnullが入る場合は比較対象外とする。
といった感じ。
nullが入った場合は2行目、空文字列が入った場合は6行目の処理を行うわけだけれども、なんとも分かりにくい。
特に、空文字来た場合に空文字同士を比較するというのは...ねぇ。
とりあえず空文字対応。
public String isNullOrEmpty(String value) {
return (null == value || 0 == value.length);
}
こんなUtilityを作ってそれを呼ぶ形にしよう。
こんな感じ。
1. if (isNullOrEmpty(hoge) || isNullOrEmpty(fuga)) {
2. if(a.equals(b) && c.equals(d)) {
3. // 処理A
4. }
5. } else {
6. if(a.equals(b) && c.equals(d)
&& hoge.equals(hogehoge) && fuga.equals(fugafuga)) {
7. // 処理A
8. }
9. }
そして何より気になるコピペコードを消し去りたい。
こんな感じ。
1. if(a.equals(b) && c.equals(d)) {
2. if ( (isNullOrEmpty(hoge) || isNullOrEmpty(fuga))
|| (hoge.equals(hogehoge) && fuga.equals(fugafuga))) {
3. // 処理A
4. }
5. }
ORとANDの結合が混じってるけど、まぁこのぐらいなら許容範囲ではなかろうか。
元のコードに比べれば幾分マシになった。
ここまで脳内のお話。
現実は「動いているコードは触るな」という御触れ光臨というオチ。
「一度リファクタリングを始めると、リファクタリングしたくてしょうがなくなる」
と聞いたことがあるが、成る程、依存性があるらしい。
Long.parseLong(s)とLong.valueOf(s)の違い
タイトルはLongだけど、Integerなんかも同じ。
parseXxx()はプリミティブ型を返す。
次の場合はlongの10となる。
Long.parseLong("10");
valueOf()はラッパー型を返す
次の場合はLongの10となる。
Long.valueOf("10");
Longクラスの実装を見ていくと、parseした結果をnewして詰めていることが分かる。
Long.valueOf("10");
= new Long(Long.parseLong("10"));
違いはそれだけ。
プリミティブ型を返すからといって、
ラッパー型に入れようとしてエラーが発生することはない。
下記ケースはいずれもエラーとはならずに正常に処理される。
(1) long a = Long.parseLong("1");
(2) Long b = Long.parseLong("1");
(3) long c = Long.valueOf("1");
(4) long d = Long.parseLong("1");
----------------------------------------------
【少し考えた】
パフォーマンスを考えると、
valueOf()と比較してインスタンス生成回数を抑えられることから
プリミティブ型が欲しい場合はparseXxx()の方が良さそうに思える。
とは言っても、大量ループ処理される場合でもなければ大した差は出ないはず。
【ローカル環境で検証してみた】
どちらも一瞬で結果が返ってくる場合と、2秒以上待たされる場合があったので分けて比較。
public static void main(String args) {
long start = new Date().getTime();
for (int i = 0; i < 100000000; i++) {
long temp = Long.parseLong("1");
}
long end = new Date().getTime();
System.out.println(end - start);
}
一瞬で返った場合 ： 約25ミリ秒
2秒以上待たされる場合 ： 約2200ミリ秒
public static void main(String args) {
long start = new Date().getTime();
for (int i = 0; i < 100000000; i++) {
long temp = Long.valueOf("1");
}
long end = new Date().getTime();
System.out.println(end - start);
}
一瞬で返った場合 ： 約130ミリ秒
2秒以上待たされる場合 ： 約2400ミリ秒
【結論】
プリミティブ型使う時は、parseXxx()を使った方がパフォーマンスが少しだけ良い。
以上。
Developers Summit 2014 (2日目)
初めてデブサミに参加したのでレポートを。
公式サイト
http://event.shoeisha.jp/devsumi/20140213/
雪の中、珍しく殆ど迷わずに会場となる目黒雅叙園に到着。
外観
内装1 廊下からふと見上げると貫禄のある看板が
内装2 これ屋内なんですよ
1コマ目の会場に入ってビックリ。
椅子がパイプ椅子じゃない!!
■１ やる気を引き出す組織風土の作り方 (藤田 晋 氏)
資料 (見当たらず)
開始時のスライド写真取り忘れました...orz
自分の業績を伸ばす ▶︎ 会社の業績がのびる ▶︎ 社員への対価に繋がる
（１） 組織
CAは社員数3000人近くいて、40代は3％程度。ほとんど20-30代。
会社の雰囲気が大学の研究室の感じ。
世代間コミュニケーションのストレスがほとんどない。
今の時代珍しく、終身雇用を目指している。
男女比7:3 理想は5:5 技術者は男の比率が高いのは仕方が無い
新卒は定期的に採用している。
部署に新卒が配属 ▶︎ 部署が活性化する これ大事。
もちろん新卒が取りやすいという理由もある。
ポジティブな社員がマジョリティ
ネガティブが伝染する前に手を打つべし。
抜擢は実績以上に人格を重視する
実績を重視した場合、人格駄目な人がリーダーになると下をつぶしてしまう。
実績がなくても人格者を上にすると、下をうまくリードしてくれる。
（人事）
[CA8]制度
2年に1回、1〜3名の取締役を入れ替える。
外れたくないから取締役がみんな頑張る。
会社は上が働くと下もついてくる。
上がやらないと駄目。
[CAJJ]制度
新規事業の開始 ▶︎ J5からスタート
J5, J4, J3, J2, J1とあがっていく。サッカーみたいな感じ。
粗利や営業利益に応じて昇格、降格する。
例えば、今期は必ずJ1へ昇格する！といった目標設定が行える。
CAは事業がおおいので、撤退ルールを決めておく事が必要。赤字が○月続くなど。
初めから撤退基準が決まっているので、突然やめろ、という心配がない。
[あした会議]制度
取締役と選抜社員でビジネスプランや課題解決を提案する合宿。
1泊2日などで実施。
意思決定の場にエンジニアが参加できるというのは大きい。
役員会で決まった事が上から下におりてくるだけでは、下に伝わりにくい。
意思決定の場に巻き込む事で、キーマンにしっかりと意思を伝える事ができる。
[社内キャリアエージェント]制度
社内で人材紹介している。
適材適所をおこなうため。
やりたいことをやる ▶︎ パフォーマンス上がる
[合宿]制度（あした会議とは別に合宿もやっている）
役員合宿、開発チーム合宿、プロジェクト合宿など。
会議室で済む内容でも、合宿することを勧めている。
仕事場で会議すると、目の前にやらないといけないことが山積していて気が散る。
お台場に合宿所を持っていて、渋谷本社からお台場に場所を変えるだけでも違う。
合宿が終わると必ず食事・飲みに行く。
そうすると仲良くなる。
[福利厚生]
力を入れている。
IT業界は採用が難しい。
エースを1000万出して採用するよりも、
今居る社員に「この会社を辞めたくない」と思わせるほうがコスト抑えられる。
[2駅ルール]
会社から2駅以内に済むと家賃援助が出る。通勤ストレス低減。
[その他]
有給以外にも休みがある。
部活も支援している。
せっかくある制度なのに「使われない」というのは避けたいのでネーミング重視。
（３）社風
半年に1回社員総会を行う。半期に活躍した社員を表彰する。
社内ポスター・トピックスメール
オープンなSNS活用
社内の活性化のため。
SNSの使い方を注意した事はない。
飲みニケーション
飲み代の支給＋翌日半休の制度もある。
社内結婚が多い
昔はそうではなかったが、今は社内結婚が多い。
安心して働ける会社でないと、社内結婚に至らない。
若手の抜擢
抜擢に怯まない。まだ無理だ、と思わずにやる。
入社1年目でも子会社の社長にすることも。
新卒入社の子会社取締役数42名。
効果がありそうでないもの （世の中に誤解されているもの）
離職率が低い会社は良い会社
離職率が極端に低い会社は逆に危ない。
働かない社員と差が出ないと、できる社員のやる気が落ちる。
ストックオプションやるから頑張れというのは危ない。
会社を辞めるタイミングを作ってしまう。金目当てになる。
美人が多い
一時的に社員のやる気があがるかも知れないが、それは継続しない。
にんじんボーナス
やりたいことに対する意欲を削ぐ。金目当てになってしまう。
仕事とプライベートの切り分け
家でも職場でも同じぐらいがちょうど良い。
まとめ
自分の働きが会社の成長に寄与している、という実感を持てることが大前提。
ネガティブは早く断て。
組織の空気は山の天気のように変わりやすい。普段からよく見ておく。
空気感、雰囲気が大事。ポジティブな人を増やす。
金で人をひっぱることは逆効果になりやすい。
金でつれてくると、金が原因で去っていく。
■グリーを支えるデータ分析基盤の過去と現在 (橋本 泰一 氏)
資料 (見当たらず)
困った事
人が増えるにつれてデータの提供がおいつかなくなった。
サービス改善が進まない。
データ分析の基盤を改善することで対応。
コンセプト
データは誰でも自由にアクセスできるようにする。
サービス増えてデータが増えてもスケールアウトできること。
ゲーム部分は Treasure Data という外部サービス。
【ゲームのデータ分析基盤】
Treasure Data
ログデータをゲーム改善のアクションにつなげる
・アクセス遷移分析
・一般的なWEBサイト分析手法をソーシャルゲームに導入
・ページ遷移
・離脱
・クリック
ジョブ管理をしっかりする
・ジョブ管理ツール
・データを社内に開放
非効率なジョブが大量に投げ込まれて、パフォーマンス劣化。
リソースは限られている。
・ジョブのモニタリングと管理が重要
クエリの先頭に、誰が投げたクエリかコメント埋め込む。
/* write by monokurotamago!! */
SELECT 〜〜〜〜〜〜〜〜
【GreePlatformのデータ分析基盤】
Hadoopベースで自作。
JDK7 + CDH4 + Apache Hive (v0.12+α)
・Hive Serer2
・追加パッチ
・独自拡張
利用状況
1日で大体5000ジョブ、数ヶ月のデータで60TB（圧縮した状態、レプリカを除く）。
全体だと180TBぐらい。
利用ユーザは100人ぐらい。大半が非エンジニア。
データへのアクセス方法
・直接アクセス
SQuirreLSQK
・グラフ化
Macaron (自社製)
・その他
Shell, Python, R, PHP, etc... ◀︎ エンジニアはこれらでバッチ作る
HQL(Hive Query Language)の中にRubyでスクリプトを埋め込んだりしている。
[近い未来のお話]
コンセプト
より速く、より高度に。
クエリの高速化、機会学習を利用したデータの活用
■越境する開発 ～あの日開発していたサービスの名前を僕たちはまだ知らない～ (市谷 聡啓 氏)
資料 (今回の資料が見つからなかったので、少し前の資料へのリンクを記載)
http://www.slideshare.net/papanda/ss-28953302
開始直前にこんな呟きが。
なんのことかと思っていたら、スライド120枚を40分でやります！ということだったw
アジャイルソフトウェア開発
うまくできてますか？できてない ▶︎ 何故駄目になるのか？
理由は様々。
正しいものを正しく作る ▶︎ 難しい
ユーザ、カスタマー、開発者間で、意図がうまく伝わらない
長く使ってもらうためには、きちんと作らなければならない。
正しいものを作る？
▶︎ 正しいとは何か。 誰かが明確な正解を持っているわけではない
▶︎ 正解を探す必要がある
注意
100人マネージャがいても何も作れない。
でも100人開発者がいれば、何か作る事ができる。
正しいものを正しくつくるには？
期待、リスクの２つのレバーが存在。
（１）期待マネジメント
関係者が互いに持っている暗黙的な望み ： 期待
期待を明らかにして適切に調整する ： 期待マネジメント
期待マネジメントは、立場・時間をこえて実施する必要がある。
期待マネジメント に関して、PMBOKには第3版までは明記なし。
4版以降から載った。
インセプションデッキ
これ使うと良い。まずはアジャイルサムライ読みましょう。
（２）仮説検証型と最短距離型
プロジェクトの開始から終了までの流れはざっくりこんな感じ。
1. プロジェクト開始時は、目的実現のための選択肢が多くある。
2. 何を選ぶべきか検証する。
3. 検証結果から、進むにつれて、選択肢はへっていく。
4. 最後はゴールまで一直線。
▶︎ 1, 2が仮説検証型フェーズ。 3, 4が最短距離型フェーズ。
開始時に「考えながら○月末までにサービスをつくりたい」
▶︎ 何も決まってない状態でこれは危ない
目的に適した方針と建付けを適用する必要がある。
仮説検証型と最短距離型で戦い方が異なる。
[仮説検証型]
リーンキャンバス（仮説）
誰のために何を提供するのか企画書を検証する。
エクスペリエンスマップ（検証）
キャンバスの課題が現れるか？提供価値が顧客の感情を変えられるか？
ユーザーストーリーマッピング（仮説）
ソフトウェアとして必要なストーリーは何か。検証したいことは何か。
インセプションデッキ（検証）
プロジェクトが開始できる状況かを確認する
ここまでできて初期コンセプト完成。
※途中で実際のユーザにインタビューを行い、フィードバックをもらいましょう！
かんばん
仮説検証型フェーズ ▶︎ タスクボード
最短距離型フェーズ ▶︎ かんばんボード
として使える。
仮説検証型から最短距離型へ変わるタイミングはインセプションデッキを見て決める。
期待マネジメント(仮説検証重視)からリスクマネジメント(最短距離重視)に重要度が移行する。
お客さんは最短距離型でやりたい
ユーザへのインタビューなど不要だ！
こんな感じで作ればよいから早くやってくれ！
でも 正しさは誰も決められない。一緒に探すしかない。
▶︎ インタビューしてフィードバックもらう事は重要
相手とどんな関係を結びたいのか。
一時的 ▶︎ 取引
長期的 ▶︎ 関係
ソフトウェアを作り上げるもの：ユーザ、顧客、プロジェクト、チーム
（３）越境する開発
自分と相手の中にぶれない軸を作る。
お客様がこういったからやれば良い ▶︎ そうではない
どちらも「そうだよね」と思える軸を持つ。
リーン開発の現場 109P
"理想とは辿り着くべき場所のところではなく、ありたい姿に向かい続けることなんだ！"
これからやりたいこと
日本全国の開発者とチームを組んで、全国で開発チームを作る事業をやりたい。
▶︎ 永和システムマネジメントやめてこれやります
アジャイルという姿勢をこれから来る人と分かち、ともに育みたい。
大事な事
開発とはたのしいものである
■デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣 (長沢 智治 氏)
資料
http://www.slideshare.net/tomohn/14d4
アトラシアンとは？
ソフトウェア開発者向けにソフトウェアを作っている会社。
ソフトウェアを愛しています。
ソフトウェアの力でこれまでできなかったことが出来るようになる
▶︎ デベロッパーはそこで活躍できる職業。
欧米ではソフトウェアデベロッパーは人気職業。 日本では...
アトラシアンの製品は多くが無料版がある。
小ユーザー向けに安い(10人未満は10ドルなど)価格で使ってもらう、スタータープログラムというものがある。
スタータープログラムでの売り上げは全てチャリティにいれてます。
公表している製品の使用ユーザー数にもカウントしていません。
アトラシアン(日本)はマリノスタウンにある。
オフィスからサッカー見れる。
イタリアンレストラン跡地なので、ピザも焼けるオフィス！
ここから本題。
ソフトウェアの世界もだいぶ変わってきている。
ビジネスを上回るスピードでテクノロジは進化する。
その中でより良いものを作る ▶︎ 活躍できる！但し辛い！！
BMLモデル
創造 成果 変革 のサイクルを１ヶ月などのスパンでまわす。
Build Measure Lean
長い時間をかけて作る要件(これまでのやり方)がこれからも通用するかは不明。
開発現場に求められる資質
開発現場だけよければよいわけではない
ユーザが使う ▶︎ ビジネスが潤う
フィードバックを受けながら開発を変えていく必要がある。
これまではアサインされたタスクを行うだけで良かった。
作ってできて動いているものが、どのように使われているか。
それを知る必要がある時代になっている。
試行のプロセス 継続的な価値提供 が重要に。
ソフトウェアを取り巻く環境の変化 (画像は公開資料を抜粋)
これからの時代は青色になっている現場（複雑）が増えてくる。
建物の建築はこれ。
ソフトウェアもこれで出来るが...
同じモデルで出来るなら、パッケージ導入で済むのでは？など。
定型で作れる物は減ってきている。
実測駆動なプロセスモデル
新製品開発
ソフトウェア！ （新たなチャレンジが多い） マッチする。
これからの開発現場
・やったことないやり方
・知らない技術
・短く定期的なサイクルタイムでつくる
（時間かけて大きく作る、ではなく、小さいものを早く作る、できたら次を作る）
力を発揮できる環境
・モチベーション
・目的、規律の見える化
・よりよいものを取り入れる勇気
自分を変える事はできる。でも人を変える事は難しい。
人を変えるには時間がかかる。年を取るごとに期間がのびる。
小学生なら数ヶ月。大学生なら半年。大人は１年。
大人を変えるには１年以上かかるが、それを待っていることはできない。
環境を変えることでアシスト
・変わりたい、と思えるような環境を作る事で、自立的に変わる。
開発のツールも環境の一種。ここを改善することで、人を変える事ができる。
確証バイアス
一度うまくいったもの、どうせうまくできないと思うもの、それから人はなかなか抜け出せない。
自分が思ったものにたいして、過去の経験にとらわれて流される。
建設的相互作用
複数人で問題を解決しようとすると、
・自分の考えを見直す機会が増える
・相手の解を一般化しようとする
・繰り返しにより応用力となる
ツール進化の3つのポイント
・作業間の受け渡しの自動化
・テスト自動化の範囲拡大
・透明性の推進と省力化
今までは成果物ごとにツールがあった。
設計はこのツール、開発はこのツール、テストは〜
これからのツールは、フェーズを越えて使えるものが必要になる。
▶︎ アトラシアンはそういう製品つくってます
[アトラシアンの製品のデモ]
Confluence
wiki.
ドキュメントを書いて、簡単にチケット埋め込みができる。
こうすると、担当者と、ステータスがドキュメントのなかに埋め込まれる。
■エンジニアだからできる自由な生き方
資料
http://sssslide.com/speakerdeck.com/masuidrive/14-a-5-enziniadakaradekiruzi-you-nasheng-kifang
▶︎ 見た事無い人は一度目を通すと良いですよ
テキストwebサービス：wri.pe
▶︎ こんなものを作りました
プログラマ35歳定年説
▶︎ 年をとってもコードを書き続けるには何が大切か？
環境が大事。
朝早くから夜遅くまで働くのは年取ってからだとつらい。
自分で働く時間を決める、勉強する時間を決める、とすることで、
年取っても若い人と同じ（＋経験では上）コードがかけるのではないか。
一日中プログラムを書いていられるほどプログラムが好きだが、
その泉源が分からないことが不安。
例えば家が火事になって、全部燃えて消えても、その翌日からなんらかの仕事ができる状態にある。
▶︎ 自分を雇ってくれそうな人、もらえる額などを把握している
特定の分野のみではなく、幅広くドットを打っておく
▶︎ 自分の世界を広げよう
日本と海外で「大人」という意味の違い
日本 ▶︎ 大人しい 大人になる
物事を荒立てることをしない。
現状維持で当たり障り無く目立たないようにする。
海外 ▶︎ 大人になる
自立した個人として自分の意見を持ち、周囲に影響を与えて社会に関わる
オマケ
DevLOVE甲子園やアジャイルサムライで見かけて気になっていた、
Ameba waterが1コマ目の会場で配布された。
中身は普通のミネラルウォーター？だったけれど、感慨深いw
以上。
はじめてのjQuery 第0歩
良いサイトを教えていただいたのでメモ。
http://coliss.com/articles/build-websites/operation/javascript/jquery-for-japanese.html
ついでに、本屋で見かけた使えそうな書籍をメモ。
[jQuery最高の教科書]
がっつりjQueryやる！という人には向かない印象だけれども、
自分のように「ちょっとjs触ってみようかな」ぐらいなら充分参考になりそう。
ORA-02049発生時の対処法
■概要
アプリサーバを起動して大量データを扱うバッチを実行したところ、
マシンリソース不足(多分メモリ)が原因でフリーズした。
15分ぐらい待ってみたものの動き出す気配がなかったので強制終了。
みんな大好き、困ったときのプロセスkill.
そしたらDBにINSERT処理中だったらしく、ロックがかかった状態になった。
■発生したエラー
ORA-02049: タイムアウト: 分散トランザクションがロックを待機しています。
■参考
http://www.searchman.info/tips/1680.html
http://www.cyberarchitect.net/blog/archives/624
http://d.hatena.ne.jp/hmeguro/20090623/1245770191
■ロック原因のセッション抽出
SELECT SID,
SERIAL#
FROM V$SESSION
WHERE SID IN
(SELECT SID FROM V$LOCK WHERE TYPE IN ('TM','TX')
);
■ロックの解除
シングルクォーテーションでSID, SERIALを個別に囲むのではなくて、
カンマ区切りらしい。
ALTER SYSTEM KILL SESSION '<SID>, <SERIAL#>';
ex) alter system kill session '123, 45';
※DBA権限が必要
■やってみた
DBA権限が必要と記載されていたのでDB管理者に依頼する必要があったのだけれど、
(依頼が面倒だったので)駄目元で流してみたら成功してしまった...
アプリで共有している一般ユーザで実行したはずなのになんでだろう。
まさか共有ユーザがDBA権限を…？
流石にそれは無いと思いたいので、他に理由があるのかなー。
