jq
jq is a lightweight and flexible command-line JSON processor. jq is like sed for JSON data - you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text. jq is written in portable C, and it has zero runtime dependencies. You can download a single binary, scp it to a far away machine of the same type, and expect
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
iPhone Wireframe Templates for Sketching – Interactive Logic
In the spirit of Open Source, I have posted some iPhone Paper Prototyping and Design templates, and you can Download The .Zip File Here. There are two layouts, and both layouts are in PDF and Viso (VSD) formats. Feel free to download and tweak them as needed. Have fun with them! UPDATE: With all the recent activity following the Smashing Magazine article on Wireframing, I’ve added the PDF files on
ポジティブ経営者の状況認識 - やまもといちろうBLOG（ブログ）
どちらかというとネガティブな方向に状況を考えがちな私にとって、リスクを恐れず積極的に事業展開をするポジティブ思考の経営者というのは羨ましくて、個人的には「いや、もうその市場は天井が見えているし、いま参入しても収益は得られないだろう」と思って投資しないような事業でも平気で進出する。しかも、自力でだ。 手広くいろんなことをやるというのは、事業意欲が旺盛なことの表れであって、それは非常に良いことだろうと客観的には思う。IT系だったかと思えば飲食店、金融、環境ビジネス等々、話題になり直近収益になりそうなところには何にでも手を出す。いままで畑違いだったはずのゲームビジネスに参入したり、そうかと思えば大規模ソーラーだ不動産仲介だとあれこれやっていて凄い。上場が近いのか、管理系の人間をたくさん採用している。そう頻繁には会わないが、あれだけたくさんリリースを出しているのなら、相当はぶりは良いのだろう。 と
全体が見えそうで見えなくて不安になる - やまもといちろうBLOG（ブログ）
酒を飲んでいるので軽くひとつ。 日本人1億2,000万の人がいて、1億2,000万の人生がある以上、1億2,000万の真実があるのは当然でしょう。 その日本人同士や日本に来ている外国の人たちが集まって日本を形成しているのですから、その数百倍の絆が折り合って日本社会というものを形成しているわけです。 ネット業界は、その絆をより良くしていきましょう、より太くして、日本社会を構成している日本人やその他皆さんの、その同士の絆を深めていくことで、日本社会をもっと豊かに、素晴らしいものにしていこうね、と考えるべきなんだろうと思います。それは基幹系だろうがアプリレベルだろうが、入り口も出口も人です。すべてのデジタルも数字も、人がこの社会で暮らしていく営みをより良くしていくために存在する。そんなことは、当たり前のように理解されているのだと思っていました。 また、人が知ることのできる範囲なんてちっぽけなもの
ゲームの言語化にこだわるわけ。 島国大和のド畜生
ゲームを語るにあたって、趣味で語る分にはそれ自体が楽しみでよいので何だって良いが、仕事でやるなら同じところをグルグル語るのがは時間のロスだから、言語化、細分化しておきたい。 毎回ゼロから一発勝負はバクチとして割が悪すぎる。 ゲームを考えるにあたって、「フレーバー（雰囲気、キャラ、世界観、シナリオ）」「システム（ゲームルール、プログラム的システム）」「ボリューム（物量）」に分けて考えるのも、「どれの話かによって、それぞれ対処と解決方法が違う」からで、これ混同したままだと同じところの話を何度もすることになってしまう。 狭義のゲーム性を例に出すことがあるのも、焦点を絞ることによって解決が簡単になる事があるから。 難しいとか簡単とかマニアックとかカジュアルとかは「針の振り加減の問題」でしかなくて、ド糞マニアックなシステムを導入しても、それをカジュアルに表現することは出来るし、ゲーム内での効果によっ
人の育て方 島国大和のド畜生
現場を回すのと人を育てるのは、わりと一緒というか、最初から戦力がそろっている場合の方が珍しいので、必然的に人を育てる必要が出る。 自分は現場でプロジェクトをグルグル回す事に特化した人間なので、そこはそれなりにこなしてきた。それ以外の能力に欠ける分、ここは多少は出来る。 自分の場合「環境が有れば人は勝手に育つ」と思っているので環境を用意する事に注力して終わりだけど。育つ気のない奴は知らん。 自分が人に何かを教えるなんておこがましいや。知ってる事はいくらでも教えるけどさ。というのが前提。 なので、自分がプロジェクトを動かしていて人に仕事を振る時に意識するのは以下の手順。 ①プロジェクトの全容を伝える。その中で担当してもらいたいタスクを伝える。 ②その相手が出来ると思うサイズにタスクを細分化して渡す。 ③出来たら次はもっと大きいかたまりでタスクを渡す。出来なかった場合はさらに細分化して渡す。 ④
不毛ながらゲーム性の定義 島国大和のド畜生
ビデオゲームにおけるゲーム性の話をすると、まず定義から始めねばならず色々と面倒くさいので、自分がゲーム性という単語を使う場合の定義を書いておく。 今後なんかあったらここにリンク飛ばしたり、随時アップデートしたりする予定。（未定） ここで扱うものはコスティキャンなどによる「狭義のゲーム性」であり、広範囲の物では無い。 ■ゲーム性とは まずゲーム性とは何かを絞り込む為に、 ビデオゲームからこれがなくてもゲームが成立するというものを削除していく。 最後に残ったものが「ゲーム性」(という考え方) 例として以下を見て欲しい。 これは有名なPC-6001mk2版のスペースハリアーだ。 敵の殆どが四角いブロックで表現される。 実際は音楽もあるし、ゲームには無関係の背景のスクロールはあるし、ハリアー自身はグラフィックで書かれているが、アーケード版とくらべると多くの物が削ぎ落されている事が解るだろう。 だが
ASP・SaaSの情報セキュリティ対策に関する研究会
ASP・SaaSの情報セキュリティ対策に関する研究会 開催についての報道資料 第１回会合（平成１９年６月２１日） 配付資料 議事要旨（ＰＤＦ） 第２回会合（平成１９年８月８日） 開催案内 配付資料 議事要旨（ＰＤＦ） 第３回会合（平成１９年１０月１７日） 開催案内 配付資料 議事要旨（ＰＤＦ） 第４回会合（平成１９年１２月１８日） 開催案内 配付資料 議事要旨（ＰＤＦ） 第５回会合（平成２０年１月２９日） 開催案内 配付資料 議事要旨（ＰＤＦ） ASP・SaaSの情報セキュリティ対策に関する研究会報告書案等に係る意見募集（平成１９年１２月１９日） ASP・SaaSの情報セキュリティ対策に関する研究会報告書等の公表及び意見募集の結果（平成２０年１月３０日）
経産省のSaaS向けSLAガイドライン：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
1/21に経済産業省のWebサイトでSaaS(Software As A Service)向けのSLAのガイドラインが公開された。 ガイドラインなので、具体例はそれほど多くないが、巻末の表に掲載されており、「可用性」のカテゴリには「サービス時間」「計画停止予定通知」「サービス稼働率」等が、「信頼性」のカテゴリには「平均復旧時間」「障害通知プロセス」等があり、「性能」や「拡張性」のカテゴリもある。 詳細はPDFを読んでいただくとして、ガイドラインに記されている確認しておいたほうがよいSLA項目の中で私が参考になると思った項目は以下のとおり。 平均復旧時間 ハードウェア故障時の復旧などを含め、通常想定される復旧時間。ハードウェアのスタンバイ機の有無、ホットスタンバイ、コールドスタンバイ、データベース障害時のリストアやネットワーク機器まで含めた想定の上での平均時間であれば、どの程度業務に影響する
高木浩光＠自宅の日記 - オレオレ証明書の区分 改訂版
■ オレオレ証明書の区分 改訂版 はてなキーワードに「オレオレ証明書」の項目ができていた。 ここにある冒頭の「(特にPKI上不適切な場面で使われる)自己署名証明書。」 という定義は私の定義とは異なる。自己署名とは限らないし、 不適切な場面とも限らないからだ。 そのためその下にある第一種〜第五種の区分の記述と矛盾が生じている。 私の定義では、クライアント側で認証パスを辿れない（検証できない）証明書 のすべてをオレオレ証明書としている。それは、サーバ側の設定ミスかもしれ ないし、設定が正しくても今まさに通信路上で攻撃を受けているのかもしれな い。証明書の発行の意図に関係なく、クライアントから見れば等しく「オレオ レ」と言っているようにしか見えない。 攻撃を受けている場合を除いて、クライアント側でオレオレ証明書となる場合 の、その原因別の区分を9月3日の注釈で書 いていた。他に第六種もあったので
あるスタートアップの資金調達失敗談 - やまもといちろうBLOG（ブログ）
某法人向けウェブサービス＆コンテンツ制作事業を企画していて、外部からの資金調達に事実上失敗をしまして（笑）、結局私を含め関係者の手金で事業をスタートするという形になった案件が一昨年から去年にかけてございました。まあ結局はどうにかなっちゃっているので問題にはならないんですけれども…。調達に失敗したのは事実なのと、今年に入って大口が幾つか決まって、調達の失敗も笑い話で済むようになったので、関係者の同意を得まして、自分なりの反省をここに書いてしまうものであります。どの案件か知っている人は静粛に。 1. 調達交渉途上での事業計画の変更、シュリンク 私が交渉の窓口をやっていたわけではないので、すべてをつぶさに知っているわけではありませんが、調達担当をしていたCFO就任予定者と、事業のコアとなる技術を持っていたCTO、会社の顔となる若いCEO候補の間で、事業の将来像や、どのくらいのペースで資金を使って
真面目に経営に取り組んだ結果、会社を潰すことは経営者にとって恥ではない - やまもといちろうBLOG（ブログ）
正直、起業ってのは運です。どんなに優れた製品やサービス、技術でも、市場の折り合いが悪かったり、巡り合うべき人と出会えなかったり、ほんとちょっとした交通事故のような取引のトラブルで世に出せず、資金が続かなくて会社が倒れてしまうことはあります。 会社が潰れるというのは、ある意味当たり前なんですよ。 だから、潰れたときのことを、みんな見ています。会社の資金繰りが悪いのに高い遊興費を使っていないかとか、派手なオフィスにいるかとか、事前に資金状態が苦しいなどの情報を出してきて協力を要請してきていたかとか、潰れそうだと言うとき連絡が取れないとか、そういう話。 再チャレンジできる社会を！ という掛け声はもちろんその通りだと思うんですが、チャレンジを容認するかはどう潰したか次第です。いろんな人に、迷惑は一応かけるわけだから。でもねえ、債権者集会に出て、100％取れるなんて思う人はいません。また、経営者同士
全体最適を考えず、自分の頭の中だけで優先順位を考えて処理するクズども - やまもといちろうBLOG（ブログ）
自己啓発本とか読んで、研鑽を進めているのはいい。上を目指すのはいいことだ。 でもなあ、お前がお前の目線で重要かどうか判断するのは駄目なんだよ。todoあるだろ。お前は考えながら手がけるんじゃなくて、上から順番に全部こなすことを求めているんだ。漏れずに全部、やるんだよ。 タスクっていうのは、下に落ちたときにはきちんと優先順位を考えて振り分けられてる。というか、お前が重要じゃないと思って後回しにしたtodo、そこに書いてあるのは金額が少ないとはいえお客様だぞ。後回しにしたら、そのお客様はうちからのサービスが来ないんだぞ。 「会社に貢献できるように、売り上げが大きいものから着手しました」とか言うな。お前の仕事はクオリティや納期を落とさずに、受注したお客様へきちんとサービスなりコードなりを制作して差し上げることだ… 売り上げが小さくても受注している理由っていうのは、私なり幹部なりが判断してるんだよ
トップクリエイターが挫折するとき（雑感） - やまもといちろうBLOG（ブログ）
私のような伏兵とか傭兵の仕事をしておりますと、どうしても人を貸したり敗戦処理を任されるケースがとても多く、ある意味でうまくいかなかったときに偉い人に責任が及ばないよう潔く斬られるのも仕事の一つだったりするわけなんですけれども、そういう動き方をするのも「今回はうまくいかなかったけど、そこを修正すれば次があるから、一度案件をターミネートして損害を被ってもやむなし」という計算が立つからであります。 ところが、クリエーターが立っていたりすると、まあだいたいにおいて「そいつが悪い」という話になるわけですね。で、クリエーターというのは自負があって、これが面白い、となると面白くなるまで頑張って作るからクリエーターでありまして、道中「ヤバイ。これは面白くならないぞ」と作ってる側が思っていたり、数字が取れないと分かってても関係者がクリエーターの首に鈴をつける要員探しになったりするわけです。 まあ、この辺は男
リーダーの有り方 島国大和のド畜生
今まで色々仕事やってきて、人に指示をする立場であった場合。 A.調整型 B.独裁者型 の２つの手法を交互に選んでいる気がする。 イイヒトのフリをしたいのが人情なので、調整型でやりたいといつも思う。 思うのだが、調整型で上手く行くことというのは滅多に無かった。 なんにしろ、人それぞれ思うところはあるし、考えもぶつかる。調整型なんかやったところで誰かにはワリを食わせることになる。みんなが満足なら聞こえがいいが、みんなが少しづつ不満を持つ形になる。 独裁型は「悪いのは独裁者」でチームの人の意見が一致する分マシだし、調整型が時間がかかってしまうところをすっ飛ばしてやれる。 でも、独裁者の心が折れる。 おそらく独裁型で心が折れないタイプというのが「上手くやる上司」なんじゃねーのと思う。 回りが死屍累々になる可能性もあるけど。会社から見ればいい上司だろう。 上にへつらい下に強く当たるとかさ。これも会社
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
「どこから突っ込んでいいやら」といいつつ具体的な指摘をしないおっさん関連 - matakimika@hatenadiary.jp
ところで「「どこから突っ込んでいいやら」と言いつつ具体的に指摘しないおっさん」が卑怯、というのは web 倫理的に同情できる一方でオープン主義に毒されすぎだと思うし、またはある意味ハッカー主義にフリーライドした不努力の正当化にもなりかねないので、「具体的な反論が来ないならおれの意見は正しいのだ」と主張したい場合でも、筋がいい論法とはいえない。「おまえが賢くよい人間になることで、おれはどんな得をするんだ？」というのが、インターネットに毒されすぎてはいない側の素朴な感想だろう。 まあ実際には「どっかに突っ込むべきなんだけどどう突っ込んだらいいかわかりません」が多いんだろうけど、「ちゃんと突っ込むひとは真面目だしパワフルだし親切だなあ」という感覚があるのも確かで。世界に向けて全レスする、というのは極論だけども、なら世界が自分をスルーしないのは当然、というのも極論だ。 いっぽうで継ぐ者のない繊細な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WEB APIのURL設計のトレンドはこれだ！WEB APIのURL設計まとめ
いきちがいのぷろぐらむあ - PG雑記/Uncrustifyのオプション - Uncrustify(0.38) のconfigのオプション指定.