2013年12月31日火曜日

2013年を振り返りつつ、2014年を考える

去年の記事

2012年を振り返りつつ、2013年を考える

今年やった仕事


今年やった仕事ですが...


  • 秋ぐらいまで、昨年に引き続き、コミュニティ系のサービスの機能開発と保守
  • 上記のサービスが体制変更となり、秋〜現在までEC系サービスの機能開発と保守


でした。

扱っているテクノロジー的にはStruts2 からSpring MVC になりました。

前者のサービスは、トータルで１年ちょっと関わることになり、個人的にも大変思い入れがあったのですが、ビジネス上の判断が下され、自分の無力を感じています。チームもとてもよい人ばかりで、それも名残惜しい物でした。

後者のほうは、リリース１ヶ月後にJoinしたので、まだいろいろなものが途中でかえって勉強になって良かったです。いわゆるフレームワーク部分を作った人が隣にいるのでいろいろ聞きながら機能追加できるのは幸せなことかもしれません。


今年の課外活動

これ、今年はまったくと言っていいほどやっていません。どうしましょ。

感想と抱負


今年は、意図した結果ではありましたが、仕事に大変打ち込めた年でした。関わっているサービスが担当変更になるという事件はありましたが、総じて仕事に集中でき、スキルの向上に務めることができました。

ただ、課題としては、

  • スキルの成長角度がまだ小さい
  • オープンソースにコミットできていない
  • ビジネス上の結果を残すことができなかった

というのがありました。

それを踏まえて、2014年は

  • オープンソースにコミットする（ために足がかりでもつかむ）
  • スキルの深さと幅をひろげていく
  • ビジネス上のとある目標を達成するために、必要な自分のスキルを向上させる
を意識して過ごしたいな、と思います。
ま、定性的ですが、定量的なものは別途個人でつくっています。

総じて、今年の路線は踏襲するものの、角度は上げていきたいという感じです。

また、個人的なところでは、今年よわい30を迎えることになりそうです。30代なにをしようか、というのも暫く模索したいと思います。

最後に、今年は本当に一緒に働く同僚に恵まれた年でした。この場でお礼を言いたいです。ありがとうございました。


小話


学生の頃使っていたFreeBSDのインストーラ（当時はsysinstall(8)）では、インストール時に下記のような区分がありました。参考リンク

Developer
Kern-Developer
User

当時私が所属していた研究室のヒエラルキーも、これに習って決められていたのですが。。。それはともかく。

自分はこれでいうと、Userレベルなままであり、今年こそはKern-Developerの足ぐらいはつかめるくらい頑張らないとなぁ、と思っています。

投稿者 時刻: 0 件のコメント:

2013年11月11日月曜日

debianのapacheでrewrite有効化メモ

たぶんubuntuでも一緒。

今組み込まれているモジュールを表示してみる

# /usr/sbin/apache2ctl -l

mod_rewriteがなかったら下記で組み込む

# a2enmod rewrite

apache再起動
httpd.confとかでonすればあとは普通につかえる。下記みたいに。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)$ http://shase428.blogspot.jp? [R]
</IfModule>
投稿者 時刻: 0 件のコメント:

2013年11月10日日曜日

JJUG CCC 2013 Fall 参加めも

今回はじめて、JJUG CCCに参加してきました。
http://www.java-users.jp/?page_id=695（これ）

なんか、devloveさんのイベントとかぶっていたので、こちらに来れなかった人もいるのかもしれませんね〜。

全般的にとても楽しく、モチベーションの向上につながりました。次もぜひ参加したいなーと。

運営の皆様ありがとうございましたm(_ _)m

今回は下記のセッションに参加しました。

参加したセッションと簡単な感想


  • JSR 310 "Date and Time API" への招待
    • 8以降だと、日付周りはJSR 310使うと楽そうだな〜と思います。
  • テンプレートエンジンを利用して、プログラマーとWebデザイナーが共同作業をする上で大切なこと
    • 問題意識の部分はかなり同意できた
    • これからテンプレートエンジン使わない開発になっていくから、どういう分業になるのか、まだちょっとわからないよな〜とかモヤモヤ考えていた
    • 自分の環境だとフロントのエンジニアとバックエンドのエンジニアがいて、デザイナー⇔フロントエンジニア⇔サーバサイドエンジニアの3層構造になっていて、またちょっと違う（が、境界の部分はいろいろ考えないといけないことがある）
    • このセッションはデザイナ⇔エンジニアの2層構造のときの話
  • ユニットテスト改善ガイド
    • 問題意識が、だいたい同じで、そんなズレてなくてよかったと思った。
    • Junit徹底入門ちゃんと読みます。。。
  • Javaアプリケーションサーバ構築・運用の勘所
    • 知ってることもあったが、知らないこともあった。とても勉強になったわー。
  • JVMコードリーディング入門 ～JVMのOS抽象化レイヤーについて～
    • いつかチャレンジしたいJVMのコードリーディング
    • やっぱc++勉強しないと、という気に
  • Over the Node.js. An Introduction to Vert.x
    • Javaにもこんなものが！（はじめて知った）
  • Spring Frameworkの今 (2013年版)
    • なんかすげードキュメントが公開予定らしいので期待
  • 懇親会
    • みなさんのLTおもしろいｗｗ

スライドリンク

公式まとめあるのかな？とりあえずtwitterで拾えたもの貼りました

LTのかた

以下完全に雑多なメモになります





◯Date and Time APIへの招待

時間の定義

UT:世界時
 観測地点に依存しない
 1928

TAI:原子時
 1955
 原子時計に基づく正確な時刻

UTC:協定世界時
 1972
 TAIにうるう秒を加え、UTIとの誤差を調整

地方標準時とタイムゾーン
 UTCに時差を加える

タイムゾーンはコンピュータの世界では標準化されている
 tz database(tzdb)
 tz databaseは随時更新されている
 例：Asia/Tokyo
 javaのupdateのたびに、tzdbも更新されている

Java 8における時刻、時間の表現

java.util.Date   ANSI/ISO Cのtime_tと同等。現在は表現のみに徹する。
java.util.Calendar  Java国際化対応(JDK 1.1で導入）。日付・時刻の作成・編集に用いる。
java.time.*   JDK8から。Date/Calendar代替が当初の目標。日付・時刻を総合的に扱うフレームワーク。規模的にもJDK8の新APIでも最大級
(JSR 310)

Dateの課題
 フィールド操作が面倒
 年フィールド+1900が実際の年
 月が0から始まる
 フィールドの直接操作が非推奨(Calendarを使う）
 日付部と時刻部が混在
 日付演算が貧弱
 フォーマットも使い勝手に難
 JDK1.1以降、一部例外を覗いてメンテナンスなし

Calendarの課題
 フィールド操作が面倒（Dateよりはまし）
 月が0から始まる
 フィールド操作の使い勝手がいまいち
 日付演算が貧弱
 日付・時刻型と認識されないことも多い

Java8でのCalendarの改善
 JDK8より、Calendar.Builderを導入

とはいえ貧弱

JSR310:Date and Time API
 Date,Calendar,DateFormatを置き換えが目的
 ISO 8601形式の表現
 immutableかつスレッドセーフなAPI

 

内部表現
 時間軸:clock
 ある時点：instant


◯ユニットテスト改善ガイド

参考書
実践アジャイルテスト

写経のススメ
 サンプル問題
 ローカルjenkins
 問題意識はズレてない

テストコードのメンテナンスをしましょう
 プロダクション以上に冗長
 量も多い
 後でリファクタリングするでは遅い
 3つ目をコピペする、ではプログラマーではない！！！！！！！！！！！！！！！！
 あとでリファクタリングする、では遅い！！！！！！！！！！！！！！！！！！！
 最初からリファクタリングする
 とてもコストがかかります





◯Javaアプリケーションサーバ構築・運用の勘所

ログ管理
 ログをきちんと取得していないシステムはスピードメーターが壊れている車と同じ

なんといってもGCログ
日時データがないログは意味が無い
GCViewer便利
 本家はstopしてしまった
 forkされてなんか開発中(datestamp対応)
GCログの上書きに注意

ヒープダンプの前に、ヒープのヒストグラムを取るケースもあるかも
通常時のヒープダンプと差分を取る

スレッドダンプ解析ツール
 ThreadLogic
 WebLogicに向いている、が、他のアプリケーションでも使える

Mbeanの分析
 Java Mission Control
 お金取られます.Java SEのAdvanceライセンス
















投稿者



時刻:





0 件のコメント:
  
































          

        

          

        

2013年10月28日月曜日


          

        









apacheのrotatelogs










よく知られていますが、httpd.conf等に下記のような記述をすることが多いかと思います




CustomLog '|/hoge/apache/bin/rotatelogs "logs/access_log.%Y%m%d 86400 540' "combined" "









マニュアルに書いてますが


http://httpd.apache.org/docs/2.4/programs/rotatelogs.html






86400ってのは、1日を表す「秒」


540ってのは、offsetなんですが、なぜか「分」なんですね。






上記を設定すると下記のようなファイルができます




access_log.2013101



知らなかったのですが、どっかのバージョンから -l というオプションがついてまして、これを使うとローカルタイム（UTCではなく）を使うようになるので、540が不要になったみたいです。



つまり、+9時間してくれると。


手元のapacheにローテートが入ってなくて、久しぶりにぐぐったので、φ(｀д´)ﾒﾓﾒﾓ...









投稿者



時刻:





0 件のコメント:
  
































          

        

          

        

2013年10月25日金曜日


          

        









mockito参考になるリンク集（あとでかく）










http://www.slideshare.net/momomoblue/mockito-12627783








投稿者



時刻:





0 件のコメント:
  








































 tmux & screen チートシート












tmux 



デフォルトはctrl + bだけど、置き換えたほうが使いやすい...



ショートカットキー




    

  • ペイン分割（縦）
    • 

      

    • ctrl + b %
      • 

    

  • ペイン分割（横）
    • 

      

    • ctrl + b "
      • 

    

  • ペインレイアウト変更
    • 

      

    • ctrl + b [space]
      • 

    

  • ペイントを閉じる
    • 

      

    • ctrl + b &
      • 

    






コマンド


    

  • 再接続
    • 

      

    • tmux attach
      • 

    








screen


    

  •  セッションのデタッチ
    • 

      

    • ctrl + a , ctrl +d
      • 

    

  • セッションの再接続
    • 

      

    • screen -r
      • 

    

  • セッション一覧
    • 

      

    • screen -ls 
      • 

    

        
    







      

    










投稿者



時刻:





0 件のコメント:
  








































Clean Code 2章のメモ










社内の輪講で使ったやつ



2章



意味のある名前





意図が明確な名前にする



これはだめ



public List<int[]> getThem() {

 List<int[]> list1 = new ArrayList<int[]>();

 for (int[] x : theList)

  if( x[0] == 4 )

   list1.add(x);

 return list1;

}





ここがよくない

・暗黙さ



こんなかんじ



public<Cell> getFlaggedCells() {

 List<Cell> flaggedCells = new ArrayList<Cell>();

 for (Cell cell : gameBoard)

  flaggedCells.add(cell);

 return flaggedCells;

}



偽情報を避ける



似情報の例



・hp,aix,sco などの変数

 unix由来？と錯覚する

・Listではないものに、hogeListとする

 acoountsぐらいにしておく

・ごく一部のみが違う名前

・小文字のL,大文字のOなど





意味のある対比を行う



ノイズワード



・数字の連続（a1,a2...）

 無情報です

 source,destinationなど意味のあるものに



・意味のはっきりしない単語

 Info? Data?

 おなじです



・aとかtheのようなもの

 明確な違いが生じるのであればOK

 zorkがあるときに、theZorkはNG





発音可能な名前を使用する



・英単語として発音できるものにしよう





検索可能な名前を用いる



・1文字の名前は小さなメソッドのローカル変数でのみOK

・長い定数はあり

 なるべく、enum、でいいんじゃね？





エンコーディングを避ける



・読めないものはよくない

・新たなことを覚えさせるのもだるい





ハンガリアン記法



・辞めよう



例）

long整数 lData

PhoneNumber phoneString; // やってしまう...





メンバープレフィックス



・m_など

 そもそもなんで昔つかってたの？？





インターフェースと実装



・Iを前置、IHogeFactory

 やめよう

・HogeFactoryImp or CHogeFactory

 Cは具象のconcreteかな





メンタルマッピングを避ける



・i,j,kはループの中ぐらいなら可

・プロのプログラマは透明性を大事にする（賢い、のではない）





クラス名



・名詞あるいは名詞句をつけろ

 Customer,WikiPage,Account,AddressParserCustomer

・Manager,Processor,Data,Info は避けるべき

・動詞を避けるべき





メソッド名



・postPayment,DeletePage,save などの動詞、動詞句

・Accessors,mutators,predicatesといった名前はメソッドが扱う値に付けるべき(get,set,isを前置しろ)

・コンストラクタがオーバーロードされている場合は、staticなファクトリメソッドを用意し、名前に引数を表現するものを含める



気取らない





１つのコンセプトには１つの単語

・複数のクラスで、fetch,retrieve,getを同じ意味で提供するとかやってはいけない

・controller,manager,driver なんかも紛らわしい

・整合性を持った語彙が大切





語呂合わせをしない



・addに、連結とコレクションの追記、２つの意味があるなどやってはいけない







解決領域の用語の使用



・すべての名前をいちいち業務用語か取り出すのは推奨しない

・プログラマーが分かる言葉（JobQueue,AccountVisitor）がよい





問題領域の用語の使用



・処理がプログラマちっくでないのであれば、業務側から用語を持ってきてもよい







意味のある文脈を加える





根拠のない文脈を与えない








投稿者



時刻:





0 件のコメント:
  

















ラベル:
















        

      









登録:
投稿 (Atom)