具体的な事実から抽象化する能力と、抽象的な要件から具体化する能力 - UNIX的なアレ
それぞれの能力について 最近、事業を推進する上で必要な能力について考え際、特にプロダクトを開発する時点では2つの能力をもった人間が配置されていることが成功の秘訣なのではないかと思いました。それがタイトルの通り、2つの能力です。 具体的な事実から抽象化する能力 抽象的な要件から具体化する能力 具体的な事実から抽象化する能力 まずこちらの能力ですが、新規事業の立案〜実行する時点までに必要とされる能力です。具体的なイシューをかき集め、それを実現することができる抽象化されたアイデアをアウトプットできる能力でしょうか。 比較的、プロデューサーと呼ばれる職種の人がこのような仕事を得意としているイメージがあります。ポイントは先程も書きましたが具体的な事実から抽象化した提案ができるという点です。ただ思いつきだけで話す人も違います。 抽象的な要件から具体化する能力 これは立ち上げ時のエグゼキューションにおい
CTOを辞めた彼のエントリーを読んで - UNIX的なアレ
nobkz.hatenadiary.jp 昨日だが、このエントリーがバズっていて僕自身もtwitterでいくつか言及した。twitterってその場の思いを素早く伝えるのは非常に便利なんだけど、コンテキストが重要なものが説明しづらいとか、フロー的な情報という問題もあるため改めてブログに書いてみる。 率直な感想 まず、彼自身がCTOじゃなく１人のエンジニアとしてこの会社にジョインしていたのであればまぁわかるよという内容だ。エンジニアとしての美学を追求し続けたけど、それじゃビジネスが立ち行かなくなった。俺のことをわかってくれるVCが日本にはいない！ まぁここまではよくある話だと思う。誰もが失敗はするし、最初からうまくいく人なんてごく少数だと思う。問題は、この事自体を環境のせいにしているということだと思う。 技術的負債を早く返しすぎたのが失敗と書いてあるが彼がそう感じているのであればそうなんだ。た
Eigooo!はエンジニアが英語を学ぶのに最適な方法かもしれない - UNIX的なアレ
英語ってやらないといけないじゃないですか。これはたぶん誰も否定はしないと思います。ただ弊社経営陣の英語力が非常にアレでですね、なんとかせんとまずいということで最近頑張ってます。 なぜメディアはグローバルに挑戦しないといけないのか : けんすう日記 まぁそんなわけでいろんな英語学習しているのですが、ここ最近、Eigooo!というアプリで英語学習をしています。 Eigooo! Anytime, Anywhere English これがなかなかよくできているアプリで、ネイティブの人と英会話ではなく英語でのチャットをするんですね。まだiOS版しかリリースされていないのですが、非常によいアプリです。 エンジニアはまずは読み書きが最優先 当然、会話は出きるべきですし、読み書きとはまた異なるスキルではあります。ただ、日本国内でエンジニアが英語が必要となるケースは読み書きでしょう。 実際に英語のネイティブ
個人的なShellTipsをまとめてみた - UNIX的なアレ
naoya_itoの火を噴いたシェルtips - Togetter これを読んでふと書きたくなったので。ちなみに僕はbash使っています。 CTRLを使った便利系 まず、UNIXな操作あたり。 キーバインド 意味 CTRL + s キー入力を受け付けなくする 画面出力抑える CTRL + q 上記解除 CTRL + z バックグラウンドに. fgで戻る CTRL + l 画面をクリア。clearと同等 CTRL + c 現在の処理を停止 CTRL + d exitと同等 CTRL + r historyからコマンド検索 emacsっぽいやつ どっちかというとキー操作に近い。基本はemacs。metaは僕はoptionに割り当ててる。とりあえず触りたい人はESCでOK。 キーバインド 意味 CTRL + a 行頭 CTRL + e 行末 CTRL + f → CTRL + b ← CTRL
文章の書き方を変えるだけで社内の情報共有は加速する - UNIX的なアレ
社内の情報共有で困っている会社は多いみたいですね。でも実は、nanapiという会社ではそこまで困っていなかったりします。元々文章を扱う会社というのもありますし、ドキュメント化して共有しようという風土が染み付いているからだと思います。 そういったこともあり最近登壇するときなど、社内の情報発信などについて話す機会が増えました。弊社では社内における情報共有のツールとして、Qiita:Teamを使用しています。 生産性を向上させる情報共有ツール - キータチーム（Qiita Team） 全員がMarkdownで文章を書く 実際にnanapiではQiita:Teamを導入してから、現在ではエンジニアだけでなくアルバイトも含めた全社員がここに様々なドキュメントを投稿しています。 Qiita:TeamはMarkdownで書けるようになっています。つまり、社内のメンバーは全員がMarkdownで文章を書く
MacのRSSリーダーはReeder2一択だ - UNIX的なアレ
さて、ついに先日からMac版のReeder2が正式にリリースされました。 https://itunes.apple.com/jp/app/reeder-2/id880001334?mt=12&uo=4&at=10l8JW&ct=hatenablog Reeder2とはRSSリーダーで、元々はGoogle Reader用に開発されていたアプリでした。当時から愛用していて、これ以外のRSSリーダーはない！というくらい気に入っていたのですが、Google Readerの停止にともないReeder2も一時的に使えなくなりました。 Google Readerの移行先としてFeedlyなどが代表的なツールではありましたが、どうしてもReeder2の使い勝手には勝てません。個人的には、スマホアプリ版よりもMac版のReeder2が重要でとにかくその使い勝手が気に入っていました。 一時的にReadKitに
いかにしてベンチャーの社内ネットワークを構築するか - UNIX的なアレ
情シス担当者なんていない 現在、nanapiは社員数30名弱くらいの会社規模です。アルバイトさんを含めると70名くらいになりますが、そのうちエンジニアは私を含めて8名。このくらいの会社の規模だと、まだ情シス的な仕事を専門的にやるような人はいません。 当然、ネットワークの専門家もまだ弊社にはいないので必然的にエンジニアの誰かがこのあたりを担当することになります。ベンチャーにおいてだいたいの場合、こういった技術的な行き場の分からない仕事ってのはCTOがやるもんです。 しかし、情シス的な仕事って本当に難儀な仕事。動いてて当たり前、高速で当たり前、ちょっとでもネットワークが遅くなるものならその時点ですでに障害です。 外注するという選択肢もありますが、何かしら社内でネットワークのトラブルがあれば少なくともその瞬間はたぶん僕が対応するなり調査するなりすることになります。どうせそうなるのであれば、自分で
さくらVPSを使って便利な開発環境を構築する - UNIX的なアレ
開発環境は難しい 最適な開発環境をつくるのっていつも難しいなーと思います。サーバ側に入って開発する人もいれば、クライアント側のIDEあげてる人もいるわけで人それぞれです。 その人に特化した開発環境をつくるだけであればそこまで難しい話ではありませんが、チームでの開発となるとそのあたりをうまく解消するのがだんだん難しくなってきます。また、新しくサブドメインが増えたりなど開発環境も常にアップデートし続ける必要があります。 このあたりを、サーバエンジニアが手動でやってると死にます。悪しきDev/Opsの対立関係がうまれてしまうので、なんとかしないといけない。 というわけで、オフィス移転をきっかけに開発環境を作りなおしてみました。以下の3点からさくらVPSを選びました。 コストを抑えたい 最近さくらVPSに東京リージョンができた ローカルネットワーク接続できるようになった 新規開発環境をつくる上での
fluentdで集約したerror_logをslackに流すと捗る - UNIX的なアレ
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
CTOとか役員とかに関する基本的な知識 - UNIX的なアレ
CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ 先日のCTOエントリが結構反響あったので続きを書いてみます。いろいろな方のリアクションみていると、CTOとか役員とかそのあたりをもう少し理解してもらいたいなと思ったのが理由です。 役員って何？ これ結構勘違いされていますが、会社法における役員というのは取締役のことです。そのため、CTOだから会社法上の役員というわけではありません。 またそれと同様に、執行役員も会社法上の役員ではありません。取締役と執行役員を兼任しているケースは多いですが、これは社内におけるそれぞれの役割を分けているためです。 それでは取締役の役目は？ まず、重要なのは以下の点です。 取締役は単独で職務執行権限を持たず、取締役会の一員に過ぎなくなった 取締役 - Wikipedia 取締役という立場自体はそれだけで職務上の何らかの権
Sensuを使ってクラウド環境の監視を効率よく行おう - UNIX的なアレ
AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。 http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/ nagiosとクラウドの相性が悪い！ 監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。 クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。 しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなけ
marked + markdown-modeの組み合わせが素晴らしい - UNIX的なアレ
ドキュメントはmarkdownで書きたい！ markdown記法がエンジニアの間ではドキュメントを書く上でのデファクトスタンダードになりつつあります。あの手の記法を取り入れることのメリットは、文章を構造化できることですね。 無駄にだらだらと長い文章を書くのではなく、見出しがあってリストがあってのように構造化された文章を書くことで考えが整理できるというメリットがあります。自分自身のメモなどにもすごく便利。 github上で書くとかなら問題はないのですが、自分自身のローカルのテキストエディタで書く場合、できればviewer的なものがあると嬉しかったりします。markdownエディターとしてkobitoはなかなか優秀なのですが、emacs厨としてemacs上で書きたい。保存はhowm上にしたい。 なんか良い方法はないものか、と探していたところmarkedというアプリを発見しました。 markdo
screenを初めて使うためのチュートリアル - Unix的なアレ
screenというものすごく便利なアプリケーションがあります。上記写真のように、1つのターミナル内で、仮想的に複数の端末を起動させることができるものです。 ただ慣れるまでは少々使い方がとっつきづらいという話も聞きますので、今回はscreenを基本的に使えるまでのチュートリアルを紹介したいと思います。 どんなことができるの？ 複数の仮想端末をあげるとどういったメリットがあるのでしょうか？実際に自分はscreenを使うまではターミナルを複数起動させ、Desktop上はターミナルだらけになっていました。 実際はそれでも問題は起きないのですが、個人的にはローカルPC側では極力起動しておくアプリケーションを少なくしたいと思っているため、screenを使うようになりました。 ただそれだけであればWindowsならPoderosa,MacならiTerm,GnomeならGnome端末があるのですが、scr
ソースコード検索ツール milkode をつかってみた - UNIX的なアレ
数万のソースコードから目的の一行を一瞬で見つけ出す、Milkode - ブログのおんがえし 先日、はてブで話題になっていたこちらをつかってみました。用途は主に自社サービス「nanapi」の開発で使おうと思っています。nanapiを開発してからすでに２年近く経過していますが、２年も経つとどうしてもあれはどこにいったっけ・・・というようなことが頻繁におきます。grep -rで必死に検索してきましたが、ひと通りファイルをなめるのでかなり遅いです。 そんなときのために、自分用のソースコード検索ツールができたときいて試してみました。 インストール〜起動まで http://milkode.ongaeshi.me/wiki/%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AD%E3%83%BC%E3%83%89 基本的には上記のままインストールすることができます。CentOS5.5(
set::combineはなかなか便利だ - UNIX的なアレ
CakePHPで、findした結果をidをキーにして配列にしなおすという作業は割とやる作業かと思います。普通にループさせて組むと以下のような感じでしょうか。テーブルは下記のような感じで。 +-------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | data | varchar(255) | NO | | NULL | | +-------+--------------+------+-----
CakePHPからToritonnの全文検索を使う方法 - UNIX的なアレ
お手軽につかえる検索エンジンとして、Senna＋MySQLで作られたToritonnがありますね。 弊社のWebサービス「nanapi」でも検索エンジンには、Toritonnを使っています。MySQLベースなので、CakePHPのActiveRecordがつかえて便利です。ただ、Toritonn使うときはSQLが拡張されているためちょっと工夫が必要です。 今回はCakePHPからToritonnを使うコツを紹介します。 テーブルを作成する まずはテーブルを作成しましょう。本家のサイトのあるようにとりあえずはこんな感じで。 CREATE TABLE search ( id INTEGER AUTO_INCREMENT, PRIMARY KEY (id), text TEXT NOT NULL, FULLTEXT INDEX USING NGRAM (text) ); 全文検索を使ってみる こ
mod_proxy_balancer配下で、cakephpのredirectを使う場合の注意点 - UNIX的なアレ
おてがるにバランシング mod_proxy_balancerを使うと、普段から使い慣れているapacheでお手軽にロードバランシングを行うことができます。 設定もものすごく簡単ですね。Virtualhostの中に書くこともできるので、NameVirtualを使ったL7バランシングをすることも可能です。 <Virtuslhost *:80> ServerName example.com ProxyPass / balancer://balancer/ ProxyPassReverse / balancer://balancer/ <Proxy balancer://balancer> BalancerMember http://localhost.localnet:8080 </Proxy> </Virtualhsot>mod_proxy_balancer - Apache HTTP サーバ
CakePHPからGoogle Analytics APIを使う方法 - UNIX的なアレ
nanapiのシステムで一部使う必要があったので、ちょっとチャレンジしてみました。 Google Analytics APIってちょっと面倒そうなイメージがあったので今まで敬遠していたのですが、まぁそうも言っていられなかったわけです。日本語ドキュメントがあると嬉しかったのですが、あんまり良質なのがないので本家を頑張って読み解きました。 ライブラリを利用する まぁいくつかライブラリはあるわけですが、PHPは公式のライブラリが用意されていません。 ただ、公式のヘルプに紹介してあるものがあったのでこちらを利用しました。画面下部にある、PHP5 OOP Interfaceというやつです。 http://code.google.com/intl/ja/apis/analytics/docs/gdata/gdataLibraries.html 使う前に取得しておくべきもの Google Analyti
CakePHPからJSONをつかうモデルをつくった - UNIX的なアレ
JSONでシリアライズされているAPIをたたくようなモデルを作ってみました。ローカルに配置しているJSONのファイルにも対応しています。 キャッシュをさせるような仕組みになっているので、多数叩くような場合にも効果的です。 modelの下に、json.phpというファイル名で保存してください。 app/models/json.php <?php class Json extends AppModel { var $name = 'Json'; var $useTable = false ; /* * jsonデータの取得 * @param string JSONファイルへのパス * @param boolean キャシュさせるか * @return mixed */ function find( $path , $cache = false ){ if ( !substr_count( $p
cakephp1.2 or 1.3でmodel/componentなどを共有する方法 - UNIX的なアレ
cakephpで複数のプロジェクトを作成したとき、お互いにmodelやcomponentを共有したいときは稀にありますよね。たとえば、nanapiの場合ですとPC版モバイル版もあったりします。 そんな時、プロジェクトは別にするけど一部共有したいmodelがでてきます。最初はmodelをコピーしてつかっていたのですが、複数管理が非常に面倒だったため共有する方法を調べてみました。 cakephp1.2の場合 共有の方法は、1.2と1.3で変更されています。まずは1.2の方法を紹介します。 app/config/bootstrap.php <?php $modelPaths = array( '/path/to/project_1/app/models/', '/path/to/project_2/app/models/', ); $componentPaths = array( '/path/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
