材料 Raspberry Pi なにはともあれ Raspberry Pi ですね。今買うなら断然 TypeB+ がおすすめ。僕のは TypeB ですが、配線がごちゃごちゃしがち。B+ は電源周りも改善されているようですし、PIN の数も多いので将来的に電子工作をやりたくなったときにも使えます。 Raspberry Pi Model B (Plus)新品価格¥4,880から(2014/9/3 00:
Ghost? 最近でてきたnode.jsのCMS https://ghost.org/download/ かるい Markdown でさくさく書ける WP からの移行方法 ここ参考にした。 http://qiita.com/hiro/items/11ea2c953d90eb946eef 実際どうなん? ただimportするだけだとurlの形式が変わる。。 いままでは /archives/1250/ とかだった。 rewriteするしかなさそう。。 コードハイライトとかも死亡 テーマが個人的に微妙なかんじする こんど自作しよう… markdown
社内LTで話したネタを再編集して。 組織に新しい何かを導入するのは結構大変です。IT業界だとここ数年はアジャイルやクラウドやビッグデータや関数型プログラミングなどが盛り上がってますが、いざ導入しようと思ってもなかなか上手くいかないことが多いと思います。   弊社でアジャイルを導入した例 僕の会社(の僕の部署)では現在アジャイル開発を採用しています。結構いい感じでアジャイルしてると思いますが、2011年まではガチガチのウォーターフォールでした。レビューが通らなくて泣く奴がいるレベル。2012年にアジャイル宣言して2年半が立ちましたが、本当にアジャイルっぽくなってきたなと感じたのは2013年の暮れくらいです。アジャイルを導入するのに2年近くかかったわけですね。 ともあれアジャイル導入には成功したわけですが、もちろん2年のうちにはいろいろあって、アジャイルが原因で辞めて行った方も何人かいて、もっと犠牲を払わずに成功できなかったのかと振り返ることもあります。   どうすればよかったのか デレク・シヴァーズの「社会運動はどうやって起こすか」が非常に参考になります。見た事のない方は是非見てみてください。 この中でデレク・シヴァーズが言っている通り、最初のフォロワーが変化を起こす上で非常に重要な役割を担います。 しかし、
引数をバインドしたい部分を &数字 にして sql ファイルを作って、、 $ cat hoge.sql select * from hoge where foo = &1 and bar = '&2' and baz = '&3'; sql ファイル実行時に引数を渡すと勝手に展開してくれる。 ''' SQL&
今朝同僚に話したら意外とみんな知らなかったので。 cp コマンドの -b オプションを使うと上書きするファイルがあったとき自動でバックアップを取ってくれる。 $ touch aaa $ touch bbb $ cp -b ./aaa ./bbb $ ls aaa bbb bbb~ そのままだとバックアップファイルは ~ がつくが、--suffix オプションで指定できる。 $ cp -b --suffix=.`date +%Y%m%d` ./aaa ./bbb
リリース手順について 正式版に向けていいテクニックあったら教えて下さい。 / リリース手順書について本気出して考えてみた #CleanReleaseManual - 邪道 http://t.co/UaqjIDxRUd — takao.oyobe (@TAKAKING22) 2014, 2月 17 大筋で同感だけども、リリースって全自動化もオール手作業もちょっと微妙なゾーンがあると思ってる。 テキストベースのリリース手順書は、 コピペする順番を間違える可能性がある。 コマンド実行後の確認を怠られるとつらい。 手順書の作り手が思っている以上にリリース作業者は何も考えずに作業を行う。 と、自動化すべき理由がある一方、 きっちり構成管理できてないと、同じ機能のリリース作業でも毎回手順が微妙に変わったりする。 その割に、「特定のプロセスが動いていたら終了するまで待つ」みたいな自動化するにはプチ面倒な作業が多い。 といった、
明けましておめでとうございます。 初詣のおみくじでは大吉が引け、幸先の良い年初めとなりました。今年も充実した年にすべく、去年のふりかえりと新年の抱負をまとめておきます。 2013年ふりかえり スクラムと現場改善に取り組んだ1年だった。 2013年はスクラムの導入に費やした1年でした。2013年1月から自分の任せられている課をスクラムチームと見立て、手探りでスクラムを実践していきました。最初の半年はプラクティスに拘るあまり効率が非常に悪かったり、プロセスを再構築していく中で品質に悪影響が出て壊滅的なバグを混入させたり、あんまり思い出したくない出来事が多かったですね。。 それでも7月を過ぎたあたりから徐々にチームが上手く回り始め、部署全体にスクラムが波及するようになり、スクラムオブスクラムを導入したり、チームを課ごとではなく部門横断的に組むようにしたりと、部署全体の情報共有・協同作業という点で1年前からは想像つかないほどの改善ができました。 技術面でのインプットは少なかった。 スクラムを推進していたこともあり、2013年に読んだ本のほとんどがいわゆるアジャイルのレフトウィングにあたるものでした。2012年は Scala や TDD や CI など、技術面でいろいろやってたことを考えると2013年は全然やってなかったなー…
    この記事はScala Advent Calendar 2013の2日目の記事です。前日はshoma2daさんの2014年こそScalaを始めようでした。 さて、今年 Scala でとあるWebサービスを開発しまして、そこで利用した Lift の RestHelper の話でも。 とあるWebサービスについて 本題に入る前にちょろっと宣伝。今年の3月に RankPlat というAndroidアプリ開発者向けのランキングプラットフォームをリリースしました。いわゆるカジュアルゲームでのユーザランキング機能を提供してくれるサービスですね。無料で使える上にランキング画面(Web)に開発者が用意した広告を表示できたりします。僕個人は既にこのプロジェクトから抜けているため詳細は不明ですが、今後 iOS に対応する予定もあるとかないとか…。 RankPlat
https://twitter.com/shitai246_/statuses/372525878904766464 これずっと考えてる。   問題が起きたとき 今現在、僕らのチームはスクラムで開発を行ってますが、スクラムも銀の弾丸ではないので問題はまぁそれなりに起こるわけです。もちろん問題が起きたらすぐに対策を打つわけですが、 特定個人のせいにしない 見積もりのせいにしない プロセスは軽量を維持する ということに気をつけることにしています。   特定個人のせいにしない 悪意を持って何かやらかしたのなら話は別ですが、当たり前の話として失敗したいと思って失敗する人はいません。 システム開発で何か問題が起きたときというのは、直接の原因になった人がいることが多いです。バグを埋め込んだり進捗が遅れたり、そういうトリガーになった人が必ずいるわけですね。ただそういうときに、その人の責任を追及してもあんまり良いことはないと思ってます。 バグや進捗遅れを個人の責任とした場合、極論すれば全て技術的な能力不足なわけです。ただ、
ちょっと前から、仕事してるときこんなのあったら便利だなーってのをシェルで書いたりしてる。 https://github.com/shitai246/shellutils ./src/shellUtils.sh はロギングとかエラーハンドリングなんかもあるけど、ロックファイル制御処理が欲しくて作ったやつ。多重起動したくないバッチ処理でのロックファイル実装はよくやる割に実装が甘い場合も多くて共通化したかった。 ./src/confirmExecCommands.sh は商用サーバでたくさんのコマンドを実行しないといけないときに使うスクリプト。単純にtypo怖いんでコマンド叩く前にひと呼吸入れたい。構造上、使えないコマンドとかも結構ありそうだけど。。 他にも何か思いついたら色々追加していく予定。シェルって結構いろいろ使い勝手がいいのでみんな覚えたらいいと思う。