スポンサーサイト

  • 2016.05.30 Monday

一定期間更新がないため広告を表示しています

  • 0
    • -
    • -
    • -

    DevLove関西 サイボウズの開発の現場 に参加してきました。

    • 2016.05.24 Tuesday
    • 03:33
    2016/05/23 DevLove関西 サイボウズの開発の現場 に参加してきました。

    当日のTwitterまとめはコチラ
    サイボウズの開発の現場 DevLOVE関西 2016/05/23
    http://togetter.com/li/978812
     

    ■kintoneチームのKAIZENプロセス 

    @mitomasan さんの発表 
    以下気になった点 

    • チームが自律的にカイゼンを進めている 
    • Kintoneはサイボウズ社自体がドッグフーティングとして、自らkintoneを使っている 
    • メールも使っておらず、Kintoneでコミュニケーションしています。
    • Issueやチケット管理などもKintoneを使用しています。
    • ドッグフーティングの問題点として、自分が使わない機能を軽るんじる傾向がある 
    • サイボウズ基本方針として、『人は理想に向かって行動する』という考えをもっている。 
    • カイゼンする時間をる仕組みを作るために、KAIZEN DAYを運用している 
      • カイゼンするための日。 
      • 規模が大きい場合はKAIZEN合宿を行う 
        • 他部署に遊んでいると思われてしまう。 
        • 障害対応に支障が出るのではと反対を受けてします
    • リモート勤務 
      • 会社自身が場所・時間に捕らわれれない働き方を実践できるのかテストしている節がある 


    ■kintoneエンジニアが紹介する品質向上のための取り組み 


    @sakay_y さんの発表 

    以下気になった点。
    • ビルドパイプラインは、コンパイルから開発現場へのデブロイまで、約1時間 
    • kintoneは日々データが増え続けている 
    • 障害や問い合わせ対応のチームのほかに、下回りから整備しなおすKAIZENチームを運用している 
    • 最近はINPACT MAPPINGを使って、アプリのゴールを検討している。(なぜ、だれが、どのように、何を) 
    • 参考書籍『IMPACT MAPPING インパクトのあるソフトウェアを作る
    • 毎日なにかしらの勉強会が開催されおり、業務に関係する勉強会であれば業務時間内でも行います。 



    発表後のダイアログがあり、いくつかテーマごとに分かれて話し合いが行われました。
    私が参加したのは『どうやってKAIZENを行っていくのか?』

    話に多く挙がったのは、KAIZENは文化であるという話でした。
    チームビルディングで悩まされているのは、どこいも同じようです。

    カイゼン活動を、日常の業務にプラスされる作業負担と捉えられてしまうと、その時点で話が止まってしまうので、なかなか難しいです。

    Agileの同じバスに乗るではありませんが、チームメンバーを如何に鼓舞するか、
    日々悩んでいます。うーむ。


     

    NightHacking Tour in Japan [大阪] by 関ジャバ に参加してきました

    • 2016.05.22 Sunday
    • 00:20
    2016/05/17
    NightHacking Tour in Japan [大阪] by 関ジャバhttp://kanjava.connpass.com/event/30552/)に参加してきました。

    当日のTwitterまとめはコチラ。
    NightHacking Tour in Japan Osaka by 関ジャバ まとめ


    ■Putting Hypermedia Back in REST with JAX-RS

    @DaschnerSさんによるRESTのお話。
    英語判らないのでひたすら、ライブコーディングを眺めていただけなのですが、IntelliJが見たこと無いような早さでプラグラムが組み上がっていくところを見ると感動しますね。ホントどうやっているんだろう。

    色々な例がGithubに上がっているみたいです。
    https://github.com/sdaschner/jaxrs-hypermedia


    ■Raspberry Pi with Java

    @steveonjavaさんによるRaspberry Piのお話し。
    デモとしてファミコンエミュを組み込んだ、見た目ゲームボーイアドバンスのようなRaspberry Pi。
    元気にマリオが動き回っておりました。権利的に?だったので写真撮らなかったけど、モニター映らないようにハードだけ取っておけば良かったな。残念。
    セッション内容は如何にこのデモ機を作成させたかが話の中心でしたが、途中からJavaステッカー配るための客いじり大会に・・・。
    見事メトロイドの主人公キャラの性別を答えてステッカGET。
    英語判らなかったので、周りの人に助けてもらいました。感謝。

    結構大きいです。

    このエミュデモ機ですが、3Dプリンターでケースを作っているだけあって、素人が作ったようなちゃちなものではなくちゃんとしたものになっておりました。
    ゲームボーイアドバンスのように折り畳めるのですが、全てプラスチックで制作するのでヒンジ部分をどのようにするのか工夫されているそうです。(六角形にするのやらなんやら)
    あと、IOポートが8つ必要なのに、Raspberry Piは6つしかないので、如何に工夫したのかとう話が面白かったです。
    (左右キー同時押しで=スタートボタンとするなどで対応)

    お二人はnighthackingの一環として、バイクで日本全国のJavaコミュニティを巡っている最中であり、
    http://nighthacking.com/
    最後は東京でJava CCCJava Day Tokyoに出られるという事です。



     

    C#実践開発手法読書会 vol.18 大阪 に参加してきました

    • 2016.05.17 Tuesday
    • 04:28
    C#実践開発手法読書会 vol.18 大阪(https://cs-reading.doorkeeper.jp/events/44202/)に参加してきました。

    今回は11.4から11章末まで。


    ■AJAJ
    AJAJ(asynchronous JavaScript and JSON)は、AjaxのJSON版の名称。
    調べてみたけど読み方が判らない。アジャジャだろうか。



    ■インタフェース1つ、実装1つの場合でのコードの臭いとは何か? 
    読書会範囲から外れるが「9.2.4 設定より規約」に記載されていた

    実際には、インターフェースの実装が一つだけであるとしたら、それ自体がコードの臭いです。

    について、議論がおきました。
    一見すると何がコードの臭いと示されているのか、判りづらいです。
    個人的には、@yanosen_jpさんが示された内容が一番しっくりきました。

    「恐らく、抽象化(もしくは要約)が足りていないまたは間違えている可能性への危険信号なのではないだろうか。例えば、犬、猫、鳥などのインタフェースを用意するのに、犬インタフェース、猫インターフェースを用意してしまっているのではないか? 
    動物インターフェースという抽象化へ至れていないという警告なのではないだろうか」


    なるほど、こらならば確かに、コードの臭いがしてくると思いました。

    第4回 IDDD読書会 に参加してきました

    • 2016.05.17 Tuesday
    • 03:45
    第4回 IDDD読書会(https://iddd.doorkeeper.jp/events/43687)に参加してまいりました。

    この読書会はファシリテーターの方が最初に要約をまとめて説明して頂いて、そのあとディスカッションするスタイル。
    要約が非常に判り易く勉強になります。
     

    今回の範囲は4.4サービス指向から4章末まで。
    4章はアーキテクチャ全般の話となります。
    注意点として、境界づけられたコンテキストの大きさがアーキテクチャによって影響を受けないようにすること。 
    4章前半で話されているCEOへのインタビューにおいて、DB変更やスケールアウトなどがスムーズに行えたという話が出ていますが、それはアーキテクチャがドメインへの制限にならなかった左例でしょうか。

     


    ■RESTとDDD 

    主な手法は2種 

    ・システムのインターフェースレイヤを境界づけられたコンテキストとして分離して、適切な戦略を用いてインターフェースのモデルから実際のコアドメインにアクセスする方法。 

    ⇒つまりユーザのタスク情報を取得するのに/user/task としたときに、ドメインオブジェクト直接取得するのではなく、何らかのインターフェース用オブジェクトを返すようにしておけば、taskドメインオブジェクトが変更したとしても、このRESTを使用している各アプリは直接変更影響を受ける度合を軽減することができる。 


    ・標準メディアタイプの利用 

    ⇒ドメインコンテキストをまたがって利用できるオブジェクトを返す。 
    ⇒DDD的には「共有カーネル」「公表された言語」など 。
    ⇒具体例としてはiCalフォーマット呼ばれるスケジュール標準フォーマット。これは公表された言語であり多数のアプリに実装されている。ドメインオブジェクト自体をicalフォーマットに合わせて作成を行う。 

     

    ■RESTを選ぶ理由 

    RESTの原則を満たす設計システムは、疎結合であるという要件も満たしているから。 

     


    ■CQRS(コマンドクエリ責務分離) 

    メイヤーが提案したCQS(Command Query Separation)が元になったアーキテクチャパターン。
    何らかの処理を実行するCommandと、問い合わせを行うQueryを分けようとうのが原則。 
    そうしないと、裏で何が処理されているのか判らなくなってしまうため、安心してQueryする事ができなくなってしまう。 

    DDD的にCQRSを使用するのメリットとしては、効率性・拡張性などの実装都合によります。 
    ドメイン駆動で、複数の集約データや、集約データをまたがるときなど単に愚直にリポジトリパターンでデータ取得するときなど、実装効率が良くない場合、効率よくデータ取得するために専用のQueryを用意するなど行います。 
    つまりドメイン駆動だから、モデル層がという話ではなく、スケーラビリティ的理由により活用されています。
    また、Queryモデルは、非正規化したデータモデルであり、ドメインのデータというよりは表示用(もしくは印刷)用のデータと見なす。 

    CQRSを学ぶ際、下記ページを参考にさせて頂きました。 
     

    Greg Young流CQRS - Mark Nijhof 
    http://d.hatena.ne.jp/digitalsoul/20100712/1278886009


    CQRS Journey 
    https://msdn.microsoft.com/ja-jp/library/jj554200.aspx?f=255&MSPPError=-2147217396


    DDDで設計するならCQRSの利用を検討すべき 
    http://qiita.com/ledmonster/items/22b00c65208dffeff7e4 


    [CQRS Documents by Greg Young]の和訳 
    http://www.minato.tv/cqrs/cqrs_documents_jp.pdf 


     

    ■パイプとフィルター 

    パイプとフィルターの特性幾つか挙げられてますが、個人的には疎結合と視認性の良さにあると思います。 


     

    ■イベントソーシング 

    CQRSと同時に使われるのが多いのがA+ES(Aggregates and Event Sourcing) 
    ドメインモデルとして、多くは非同期つまり結果整合性で済むことは多いと思います。 
    しかし、難しくなるのがUI設計。 
    非同期で発生したエラー通知などは、どうすればいいのか今でも試行錯誤です。 

     

    読書感想 『カンバン仕事術 チームで始める見える化と改善』

    • 2016.05.08 Sunday
    • 00:57
    評価:
    Marcus Hammarberg,Joakim Sundén
    オライリージャパン
    ¥ 3,888
    (2016-03-26)
    Amazonランキング: 4856位

    ■カイゼンを促すツール
    初見の開発が多く、同じ開発内容は2つもないという状況の中で、如何にボトルネックを見える化するか、その解へ繋がるツールの1つがカンバンなんだろうなと思いました。
    一見正常にタスクが流れているように見えている場合でもWIP(Work in Process)を制限することで、常にカイゼンの機会を探るなんて思いつきもしませんでした。

    後、この本で出会えた一番の言葉は、
    『始めるのをやめて、終わらせることを始めよう』
    ほんとその通りです。

    読書感想 『システム開発「見積もり」のすべて』

    • 2016.05.08 Sunday
    • 00:42
    タイトルにあるとおり「工事進行基準」会計に準ずるための開発工程「見積もり」の本。
    いつ開発規模・工程を見積もるのか、
    どのように見積もるのか、
    どうやって見積もり内容で開発していくのか、
    プロジェクト全般の流れを、実践で培われた内容を元に紹介されていました。

    個人的には野村総合研究所で使われている工程定義の表と、
    EVMの実践的な見方を学ぶ事が出来たので満足しています。

    しかし見積もり手法自体は深く記載されていませんので、
    他書籍を参考にする必要がありそうです。

    セルフレジでポイントカードの出すタイミングが変わった

    • 2016.04.02 Saturday
    • 00:06
    小さな事でもカイゼンするんだと驚いたこと。
    先日ライフのスーパーで買い物したときに、セルフレジで会計しようとすると、
    ライフのポイントカード提出するタイミングが変わっていました。

    ■今まで
    1. 財布だす。
    2. ポイントカードをレジに通す
    3. ポイントカードを財布にしまう
    4. 財布をしまう(または近くに置く)
    5. 商品をレジに通す
    6. 財布をだす
    7. お金を払う
    8. 財布をしまう
    このような流れでセルフレジを使っていました。
    一番面倒だったのが(3)の工程。
    商品をレジに通すには片手では難しく、ポイントカードを通した後、財布にしまい、その財布もしまわないといけなく、小さな煩わしさを感じていました。

    ところが、先日セルフレジを使用してみたところ、

    ■現在
    1. 商品をレジに通す
    2. 財布をだす
    3. ポイントカードをレジに通す
    4. ポイントカードを財布にしまう
    5. お金を払う
    6. 財布をしまう
    このようにポイントカードのレジ通しが、商品をレジに通したあとになったことで、
    財布を出すタイミングが一回に済み、大変らくになりました。

    このような小さなカイゼン。なかなか気づく事難しいと思いますが、流石だなと思いました。
    以上、街中で見つけた小さなカイゼンでした。
     

    Selenium WebDriverでTextarea要素のテキストデータ取得する際の改行コードについて

    • 2014.09.17 Wednesday
    • 11:02
    Seleniumu WebDriverでTextarea要素のテキストデータを取得するときに、取得方法によって、改行コードがついて来たり、亡くなったりします。
    良く忘れるので、自分メモ。

     

    ぐるぐるDDD・Scrumに参加してきました!

    • 2014.03.23 Sunday
    • 13:46
    2014/03/15にDevLove関西で開催された『ぐるぐるDDD/Scrum - ドメイン駆動設計。モデリングと実装のうずまきをまわしてみよう』に参加してきました。
    http://devlove-kansai.doorkeeper.jp/events/8246

    DDD本(鈍器)を読んで、悶々としていたところに、DDDのワークショップを開催するということで、これ幸いとスタッフとして働くことを条件に参加してまいりました。


    今回は、講師をして頂きました原田様、会場提供頂きましたエムオーテックスの井上様には多大なるご尽力頂きまして、誠に有難うございました。
    改めて御礼申し上げさせて頂きます。
     

    いろふ式暗号を作ってみよう♪

    • 2013.12.17 Tuesday
    • 00:24

    この記事は、いろふ Advent Calendar 2013の16日目の記事です。
    もう17日になっていますが、気にしたら負けです。

    昨日は、@Posauneさんの「いろふさんの一意性を証明する #irof_history」でした。
    いろふさんはやっぱり、謎なんだなと思いました。


    さて唐突ですが、本日は、いろふさんを使って、
    オレオレ暗号ならぬ、
    いろふ・いろふ暗号を作ってみたいと思います。

    なぜそんな事をするのか?
    何となく、いろふさんは謎なので、鍵にするのなら、
    丁度いいと思ったからです。




    さて、暗号式の作戦ですが、
    鍵にはある程度の複雑さと、ゆらぎが必要ですので、
    ここはirofさんのtweetを利用したいと思います。

    作戦はこうです。
    (1)いろふさんのtweetの中から、ランダムに2件取得
    (2)2件のtweetをハッシュ化、XORで1つの秘密KEYを作成
    (3)暗号化したい平文メッセージを秘密KEYで暗号化
    (4)暗号化したメッセージを今度は復号化してみる

    醍醐味は、取得した2件のTweetからは、暗号キーはサクッと作れますが、
    暗号キーからは、どのtweetを使用したのか判らないような暗号を作ってみたいと思います。
    では、さっそく作ってみましょう♪
     

    ■まずはTweetからランダムに2件取得


    Tweetを取得するにはTwitterのAPIを利用するしかないのですが、
    C#には「linq2twitter」という便利なライブラリがあります。


    ライブラリを使うと、たったこれだけで、
    指定したユーザの最新200件のTweetを取得することができます。
    (200件はTwitter1.1の一度に取得できるMAX件数)

    あとはこのTweetリストの中から、2件のTweetを選びます。
    ランダム取得もLinqを使って1件取得するとなると、

    こうなります。

    ビバLinq!便利。
    早速、プログラムで2件ランダムにTweetを取得します。



    つぎは、取得したTweetを使って暗号キーを作成してみます。


     

    ■2件のTweetから暗号キーを作ってみよう



    どのTweetから、作成されたのか判らないようにしたいので、
    まずはTweetのメッセージ文章をハッシュ化させてみたいと思います。

    ハッシュ化は、MD5を使うと簡単に行えます。

    あとは2件のTweetをそれぞれ、ハッシュ化を行ったら、
    XORで1つにまとめてみます。
    これを秘密キーとします。

    早速、プログラムで実装してみます。

     

    ■秘密キーで暗号化してみよう



    作成した秘密キーを使って、平文を暗号化してみたいと思います。
    暗号アルゴリズムには現在最強のAESで行ってみたいと思います。
    C#では標準でAESアルゴリズムが用意されていますので、
    簡単に暗号化する事が出来ます。

    それでは、プログラムに実装してみましょう。


     

    ■暗号化した文章を復号してみよう



    復号は先ほどの暗号化とほぼ同じプログラムとなります。


    プログラムに実装してみましょう。


    無事、復号する事ができました。

     

    ■いろふ式暗号の特徴



    作ってみて判ったのですが、

    ■特徴その1
    圧倒的に、強度が低い(汗
    なぜなら、Tweet件数を200件としてしまっているので、
    その中から、ランダムに2件選んでいるということは、
    200*199回、総当たりされたら、突破されることになります。
    瞬殺ですね♪


    ■特徴その2
    時限式暗号で、賞味期限がある!
    200件のTweetは古くなると見れ無くなります。
    つまり、いろふさんが沢山つぶやくと、そのぶん暗号の賞味期限は短くなります。


    あとは、Tweetのコメントを秘密キーにしているので、
    似たような内容のコメントが続くと、暗号強度が下がるのですが、
    そもそも200*199回の総当たりで突破されるので、どうでもいいです。


    一応今回のプログラム(C#4.5)はコチラになります。
    https://github.com/kawakawa/IrofCryptographic.git
    誰得?ですが置いておきます(汗


    明日は、@kazuhito_m さんの「「いろふさん絵描き歌」じゃないヤツ、歌ってみた #irof_history」です。
     

    PR

    calendar

    S M T W T F S
        123
    45678910
    11121314151617
    18192021222324
    252627282930 
    << June 2017 >>

    selected entries

    categories

    archives

    recommend

    recommend

    recommend

    recommend

    profile

    search this site.

    others

    mobile

    qrcode

    powered

    無料ブログ作成サービス JUGEM