まさかの日記

最近まともな文章しか書けなくなってきました

カテゴリ: 技術系もろもろ

ssd速すぎ。vmにwin7入れたりが、ありえない速さ

とりあえずその辺のQiita記事を見ながらrorとか入れてみたり


さすがにまっさらな環境だとnokogiriのビルドでコケたりはしないらしい。

あとrbenvで2.2.3を持ってきたりするが、異常に速い。前がcore2duoとかだからかもだけど。


キーボードがパカパカうるさいけどこれはこれで気持ちいいかも。

あんまりカスタマイズせずにどこまでデフォルトでいけるかやってみる(なんとかハンマーとか入れずに)

5分くらい考えて出たアイデアがあれば、それ以上のことはもう出てこないので、それをベースに、あとはやりながら変えてくだけ、みたいな結論に。

数年前に某氏が言ってたアイデアを思い出しながら。

始めました
自サーバでセルフサインアップも有効にしてあるので、お声がけください。

これは良い

某アプリのソースもまあまあすぐ動かせた。

dllとかの依存関係とかが若干めんどくさいし、webアプリのホームディレクトリってどこやねん、みたいなハードルは若干あるけど、nokogiri入れようとしてハマる、みたいなのに比べたら全然楽だし。

なんとなく気付いたら脳の研究みたいなことをやってる感じになってて、理解が深まってると自分では思うのだけれども。

人間観察、動物観察、脳のシミュレーション、認知機能が低下した状態では人間はどのように行動するか(これほんとに失礼な話とは思うのだが)、というあたりをずっとみてきて、まあなんというか、人間にはあんまり興味なかったんだけど興味出てきた、みたいなところに着地した。

人間の理解が人並みには進んだかな?まだまだかな。

プロダクト企画が定型業務化できない、というのはそれはそれであるべき姿なんじゃないかな。
手順通りやれば何かできる、というものではないかなと(そういう手法の話もあるだろうけど、ボリュームがないので)



ユーザー側からしたら、使うものがフルスクラッチかSaasかはそれ自体はどうでも良くて、結局は10年とか20年単位での、内側の社員の退職リスクとかも考慮したコスト。

提供者側でも充分なメリットがあれば、ある程度は継続可能。
まあ一桁二桁安い基幹システム、みたいなものも色々出てくるとは思うけど。。世代交代前提みたいな話かなと

ブラックスワン的な。


ちなみにthe big shortってのは、主人公(?)の人が悩みに悩んで空売りポジション解消、みたいなところだったのかなと(言葉の意味はよくわかってない)

スタートアップの話と同じ、と思ったらそういうblogというかmediumがすでにあった。

まあ付け加えるなら、ゆっくりとブラックスワンが現れつつ有る業界からはさっさと去ることですな。。

あとで全体図(ソリューションマップ?)を書く

◾︎技術選択方針
そのときのほぼデファクトスタンダードなものを使う。
顧客要求を満たしていれば有償無償は問わない
が、原価は人件費以外に、トレーニングコストと維持費を見込む。

まあ、生産技術の役割を持つイメージ。
ラップして自社ライブラリ化とか

自社ライブラリに登録する手順を、明確にして、誰でも申請、承認されたら使う。

一方で、車輪の再発明推奨

◾︎収支kpi
チームで食えていれば基本的にはサービス改善、プロダクト開発していたりする

保守系売り上げを主な食い扶持とする(難しそう)



どのpjで何を使っているかをカタログ化する。
誰がそれに精通しているかを見える化する。
社内オープンソース的なもの。コアでないものはオープンソース化する


◾︎運用系サービスについて
メニュー化して、まあ今と変わらないイメージだが、よりマネージドを指向する。オンプレクラウド問わず丸抱え。

データについてもやる。、つまりdbaみたいなとこもやる。


クラウド寄りなsierみたいな雰囲気を指向。

◾︎お客さんにとって嬉しい点
コストとリスクの将来見込みが立てられること。
事業主内で技術者と技術資産を抱えることのリスクを肩代わりするイメージ。

◾︎こちら側のメリット
モノリシックな一枚岩アプリから、ライトなつなぎこみソリューションまで、カタログ化によるコスト最適化

技術のある程度の集約、発散を防ぎ、技術者のやりがいも確保(?)


なんとなくの筋悪感というか、現実的でない点が結構あるな。。すり合わせが必要。
外部から来た役員が頑張って出して来そうな内容w


あと営業が難しそう。ソリューションマップを理解して提案、みたいなのはハードルが高い。のでそこはざっくりで現場側に投げるとか。、
となると現場側にセールスとコンサル的な要素が欲しくなる


全体的に、お客さんから選ばれる理由が薄そう。同業者に比べて優位性が不明。

高い技術力で利益を出している状態を志向するかどうか、

かつ、その余力が有るか。かなあ。結局。



ギリギリのところにいる場合、そんな不確実な道は通らないよなあ。



我ながら、なんだかつまらん奴になったなあ

機械学習とかみてたけど、一周して戻ってきた。react-railsプラスwebsocketでプロト作ってたけど、ポーリングで充分かも。。

みたいな事書いとかないと、自分が何やってたかすぐ忘れるんで。

見たけど、後継者育てようと思って長編を作るけど、結果的には才能を食べてしまう、みたいなこと言ってて興味深い。

テクノロジーベンチャーが成り立ちにくい理由がこの辺にある、気がする

映画とソフトウエア製品とで、作りにくさみたいなものには本質的な差はない。
ただ、非エンジニアのリーダーがソフトウエア製品のビジョンを示すことが難しい。プロトタイピングに必要な手間が大きすぎる。

また、誰でも同意できるほどわかりやすいビジョンは退屈に感じるため、それが実装フェーズの課題になりやすい。

対策しては例えば、部品単位に良いものを作らせ、それを組み立てる、というやり方が良いような思える。

アプリが作りたいんじゃなくて、アプリを楽に作れる仕組みを作りたい、ってことなんだなと。


生産技術みたいなところで仕事を始めてしまったので、そういうバイアスが掛かったまま現在に至る、ということなのかも。


というわけでforce.com入門編はクリアしたので、elixir/phoenixからreact方面に行こうかと。

ここ10年くらい(サービスの監視とかするようになってからずっと)、家に居る時には何か通知来てないかとiPhoneをずっと手元に置いていて、そのためについつい触って無駄にはてブとかしてたんですが、全然触らなくなった。

よかったよかった。、素晴らしい。

Apple Watchである必要は全然無いんだけど。

まだよくわからない。過度な最適化の結果、のようにも聞こえるが、会長退任という事は黒判定認識ということかな。

すごく気に入っているだけに、残念、がっかり、としか言いようがない。

乗ってると後ろ指指されるのでは、みたいな話もあるけど、悪いけどほとんどの人はVWと国産車の区別もつかないと思うよ。(ビートル除く)

割とすぐ忘れられる展開に一票。

■GitHub ・ Build software better, together. ▽https://github.com/tokuhirom/avans/blob/master/README.md


■GitHub ・ Build software better, together. ▽https://github.com/tokuhirom/tinyorm/blob/master/README.md


この辺らしい。あと普通にWebAPIとかangularとか。



この辺も読んでからJava8いじり始めるといいらしい

戯言ですが。。自分用メモ。


■既存パッケージの競争力が充分に高いのであれば、そのままAWSなりに乗せて動かすだけでOK。だがそうではないのであれば。。。

もしそうではないのなら、競争力を高めるのが先。
競争力を高め、維持する、という活動が継続可能な状態にすることが先。


■”クラウド”で解決するのはデリバリー上の課題のみ。

”クラウド”に載せたことで競争力がUPすることは無い。
インフラの調達スピードが早くなる、顧客側のインフラ初期投資が抑制できる、などという調達上の課題が解消されるだけ。
それを見て競争力が上がったと勘違いしてはいけない。


■”クラウド版”に「ドアノック商品」を期待するのは、「初期費用の工数で稼ぐSIモデル」を継続することになるが、それがやりたいことなのか?

つまり「初期費用の工数で稼ぐ(=フロー型)」を続けたいのか、月額課金の顧客数を増やしてストック型にしたいのか、をまず明確にするべき。


■事業計画上で気をつけるべきは、どっちに転んでも大丈夫なように戦略を考えておくこと

工数ベースの事業が拡大するかもしれないし、ストックベースが拡大するかもしれない。どっちもうまくいかないかもしれないが、そのときにどうするか。撤退可能なのか、撤退して致命傷を受けないためにはどうすればいいか。

ストック型が充分な売上に達するまでは、ストック系の事業に充分な人材を張ることは出来ないが、そのことで事業の成長スピードが遅くなることが起きてはならない。(ので繊細な舵取りが必要なのか、あるいは、、、全員が開発も運用もインフラ構築も出来るスーパーな人材であれば当然問題が起きる可能性は減らせるが。。)


社内でAWSの啓蒙っぽいことしてるけど、かなり引きが弱い。

昔、いろんな会社でUnixとかLinuxとかサーバとかの社内教育を散々やったけど、全然ものにならなかったことを思い出すなあ、と。

期待もしてないし、絶望もしない


やっぱAPI系は必須として何を選択したらいいんですかね?
と地元の知り合いに聞いてみた結果を共有しときます。

***

バックエンドは当然REST API
実装よりも設計が難しいので要注意
Jersey、Gsonは必須

WEB Viewならspark
http://www.sparkjava.com/

とはいえWEB Viewは不要とのこと。
AngularJS
bootstrap
でシングルページWEBアプリが王道

ORマッパーは、hibernateか、あるいは薄く自作
パフォーマンス重視するなら最終的には必ず自作になる

Seasar、Seasar2系はもう終わり

ちなみにnode.jsよりはvert.xかも

やっぱDockerすごい


(このへんから脱線して開発方法論の話)


社内でメールは不要
チャットから拾ってチケット管理に登録
なので全チーム共通でのチケット管理ツールは必要

ていうか開発方法論も見積もり手法ももはやどうでもいい
作る人で百倍以上違うのに見積もりしても意味が無い
できない奴は一生出来ないし、できるやつなら一日で作れる

進捗何%ですか?は無意味
あと何日で終わるか?だけが重要
もし無理そうならほかの人に変わってもらうだけ

9時過ぎて会社に残ってる人がいたら、困ってたりハマってたりしていないかを上司がチェックする
毎日10時過ぎまで会社に居るのは何かが起きているというアラート
単にこだわってるならOK、困ってて何日も進んでないなら担当を変更する
問題が起きたら出来る人のチームで対応する。


UIは、このUIが最適である、というのをデザインチームが決める。
それを元にエンジニアチームが実装する
リリースはエンジニアチームの都合で決める(延期する)


そもそも管理も何も必要無い
良いメンバーで、雰囲気良くしていればものすごいパフォーマンスを出せる

アプリの仕様書は不要。
そもそも仕様はテストケースで表現する。中身はどんどん変えてOK

納品しない開発、ソニックガーデン、あれは良い

やっぱそれは無理かと。ある程度概念が頭に入ってからじゃないと。

まあマネジメントコンソール自体が判りにくくさせている、っていう話もあるかもしれないけど。


なので裏でどういう仕組みになってるのか、っていうのが頭の中でイメージできてる状態にする、っていうのがまず第一に必要なのかなと。


(a * a ) % c == ( a % c * a ) % c

(a * a * a ) % c == ( (a * a) % c * a) % c

(a * a * a * a ) % c == ( ((a * a) % c * a) % c * a) % c


コレ知らないと厳しい


(a * b ) % c == (( a % c ) * ( b % c ) )% c


一般的にはこういう公式しか出てこないし。

合同式とか意味判らんし。


アルゴリズムを学ぼう (アスキー書籍)
KADOKAWA / アスキー・メディアワークス
2014-04-10

ぶっちゃけ非常に少ないというのが現状かと。

2014-6-14追記。

■【連載】BtoBマーケティングの極意!学びと実践の現場から:第4回 企業サイトの運用を激変させるマーケティングオートメーションツールの衝撃体験 (1/3) - ITmedia マーケティング
http://marketing.itmedia.co.jp/mm/articles/1406/13/news006.html






2014-4-24追記。

■インバウンドマーケティングの説明を自分のおばあちゃんにしてみる。大変! ▽http://info.mktgengine.jp/weblog/how-to-explain-inbound-marketing-to-my-grandma ””




2014-4-4 追記。

■HubspotのMarketing Grader(マーケティンググレーダー)とは その1 | Hivelocity ハイベロシティ ▽http://www.hivelocity.co.jp/blog/13797 ””


■ECサイトのインバウンドマーケティング元年がやってきた - 前編:ECサイトでもインバウンドマーケティングが重要な4つの理由 | eコマースコンバージョンラボ ▽http://ecclab.empowershop.co.jp/archives/1757 ””



***


<概要説明的なもの>

■インバウンドマーケティング | 株式会社24-7 ▽http://www.24-7.co.jp/ja/services/digital-marketing/

■コンテンツ型フリーミアムを実践する会社Hubspotとは? | The Content Marketing ▽http://thecontentmarketing.com/what-is-hubspot/ ””

■個人・中小企業がHubspot(ハブスポット)のようなインバウンドマーケティングを自力で行う方法 ▽http://www.amelt.net/imc/seosem/435/ ””


<マニュアル的な何か。Wikiなども含む>

■HubSpotマニュアル - 24-7 ▽http://hubspot.24-7.co.jp/ ””


<連載記事、Blog>

更新が続いているもの

■Hubspot | インバウンドマーケティング/Facebookアプリ/Web制作 Hivelocity ハイベロシティ ▽http://www.hivelocity.co.jp/tag/hubspot ””

■Marketing | DX.univ ▽http://dx.24-7.co.jp/category/web-marketing/ ””


更新が終わってるぽいもの

■【WEB担当者必見】第2回:ネコでもわかる!新規訪問客を呼び込むブログを書く20のアイデア! | DX.univ ▽http://dx.24-7.co.jp/inbound-cat02/ ””

#二回で終わってる



<ニュース記事>

2014年のものは今のところ無いみたい。


2013年

■インバウンドマーケティングは解ではない:Hubspotダーメッシュ・シャアインタビュー : ライフハッカー[日本版] ▽http://www.lifehacker.jp/2013/11/131105inbound_marketing.html ””


■HubSpot Day in Tokyo:狩猟型から農耕型へ――HubSpotとマーケティングの新時代 - ITmedia マーケティング ▽http://marketing.itmedia.co.jp/mm/articles/1306/07/news090.html ””

■HubSpot INBOUND 2013に参加して感じた、運営面での6個の気づき ▽http://salesforce.crmstyle.com/blog/bid/330222/HubSpot-INBOUND-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E6%84%9F%E3%81%98%E3%81%9F-%E9%81%8B%E5%96%B6%E9%9D%A2%E3%81%A7%E3%81%AE6%E5%80%8B%E3%81%AE%E6%B0%97%E3%81%A5%E3%81%8D ””


2011年

■ほぼ日刊イトイ新聞 - “Unusual(変わってる)...” ▽http://www.1101.com/hubspot/2011-07-15.html ””

■HubSpotが断然カッコいい理由 | PRFREAK ▽http://blog.prtimes.co.jp/yamaguchi/2011/09/hubspot/ ””




日本語記事の少なさは、スタートが月額200ドルってのがそうさせているような気が。

このページのトップヘ