arveltのソフトウェア技術メモ

Arvelt's software technology memo

パーフェクトPythonを読んでのメモ

python book

１章−９章が、言語仕様のことについて書いてあるので、まずここを読み込むのがおすすめ。ここで概要を抑えて公式ドキュメントを読むとすんなり頭に入りやすい。

実践的な部分については、「Pythonプロフェッショナルプログラミング」を読むほうが良いかもしれない。

 

pepsについて

poythonの禅。import thisで読める。

変数、定数について。

論理型、シーケンス型、セット型、辞書型について。

条件文、演算子、ループ、リスト内包表記、例外処理について。

関数について。

クラスについて。

モジュールとパッケージについて。

 

１０章でコマンドラインアプリケーションについて触れていますが、

pythonのデータ構造をいかに扱うかという点を書いているのでここは手を動かしてみるといい感じかも。

１２章でライブラリとして配布する方法について。大事なものはすでにあるわけで、かゆいところに手が届くようなことを解決するコードを書いたら、ライブラリにして公開したいですね。

 

これ以降はライブラリの紹介みたいな感じになるので気になるとこだけメモ。

１４章の最初にあるWSGIはWAFの基礎になる気がするのでおさえたい。Djangoとかflaskとかもこれの上で動いてたはず。

趣味プログラミングように１６章のマルチメディア、１７章のネットワーク系をさらっておくと遊べそう。

 

基本わかってない私は何度も読み返さないといけないと思う。

 

パーフェクトPython (PERFECT SERIES 5)

パーフェクトPython (PERFECT SERIES 5)

 

 

three.jsをさわってみた話

javascript three.js

3Dに興味あります。そこでjavascriptで3Dに関することを扱うライブラリでthree.jsというのを触ってみました。レンダリングにwebglを使えることが特徴です。コード書いたのだいぶ前だけど忘れないうちにメモ。

 

○three.js

http://threejs.org/

 

○three.jsを使って作ったもの

ゲームっぽいもの。すぐに動きます。

https://dl.dropboxusercontent.com/u/19360039/threejs-sandbox/examples/game_avoidblock.html

 

○ソースコード

https://github.com/arvelt/threejs-sandbox/blob/master/examples/game_avoidblock.html

 

3Dのあれやこれをあれほどの少ないコード量で書くことができます。3Dのことを全く知らない状態から初めていますが、とりあえず動くものを作ることができました。

 

○気づいたこと

・3Dがそもそもわからない

サイトならここ

http://wgld.org/d/webgl/w003.html 

 

本ならこれ

 

明解 3次元コンピュータグラフィックス

明解 3次元コンピュータグラフィックス

 

 

１，２，３章あたりに、コンピューターで3Dを扱うことの体系的な概念が書いてあるので、ほんとうの初学者におすすめ。

 

コンピューターで2Dとか3Dとかって意味わからんしと思ってたのが、ぼんやりとわかるようになる。

 

・んでthree.jsで何ができんの

http://threejs.org/examples/

公式サイトのexsample。

 

http://stemkoski.github.io/Three.js/

three.jsのサンプルを集めたサイト。こういうことやりたいときはどうやんのってときに探しに行くときに眺めると閃きを得たりする。

 

http://wgld.org/d/webgl/

webglはそもそもなんやねんというのがわからないときなど。体系的に書いてるので読みやすい。

 

・実際にとるべき手順

１．まず3Dの概念をおぼろげに理解する

２．それらがthree.js上でどう抽象化されているか把握する

３．自分がやりたいことは3D的にどう実現したらいいかを分割する

４．その分割した要素をやってるサンプルを探す。

５．ソースを読んで真似をする

６．コード書く、動かす、デバッグする。

７．４－６を繰り返す。

８．完成！

 

・まとめ的な

three.jsはシーン、ジオメトリ、ライト、カメラ、レンダリング、を書いていくと完成する。

three.jsはいまだ黎明期であり、バージョン上がれば動かなかったりするようなものがざらにあるので注意しないといけない。

3Dのモデルは形状と表面を分けて考える。

表示するものがないとなにも意味が無いので、3Dモデリングが最も重要。

3Dの本質は数学の世界なのでかつて因数分解でつまづいた私には手に負えない。もし続けていくならば、抽象化したものに対する操作の概念として把握しなければならない。

 

小さなチーム、大きな仕事(完全版)の読書メモ

book

小さなチーム、大きな仕事を読みました。サクサク読めていいですね。

１つのことを、自分たちだけでやれ。技術をどうこうというかは、意識を高めてくれる良書です。

 

内容メモ

現実の世界とは場所ではなく言い訳だ。何も試さないことの正当化だ。あなたには関係ない。

現実と折り合わない計画にしたがうのはもっと恐ろしい。

本当のヒーローは仕事をさっさと片づける方法を見つけ出し、とっくに帰宅している。

すごい製品やサービスを生み出す最も単純な方法はあなたが使いたいものを作ることだ。

 

中途半端な1つのものよりも、とてもよくできた半分の大きさのもののほうがいいに決まってる。

始めるときは、ディティールは忘れろ。

一番大切なものが残るまで切り落としてそれを繰り返していく。

副産物を生み出していることすら気づかない。だが副産物も売れる。

 

どういった問題を解決するのか？ほんとにそれに価値があるのか？

睡眠をとろう。

問題を可能な限り小さな要素に分解する。

 

模倣の問題は理解を飛ばしてしまうこと。

競合の一つ上をいくのではなく、一つ下回るようにしてみる。その代わりそれをうまくやる。

 

顧客が常に正しいと信じてはいけない。

既存の顧客にこだわり続けると、新しい顧客が切り離されてしまう

 

偉大な料理人はレシピを公開し料理本を書く。ビジネスも彼らを見習うべきなのだ。

試してもらう。それが顧客にとって手放せないものであるなら、利益を得られる。

 

まず自分自身でやってみる

限界の時こそ人を雇う、その前の段階ではない。

有能な人でも、必要のない人間を雇うことはない。

 

顧客と社員の間に人が多いほど、顧客の声は歪んだり失われる。

ポジティブな意見よりネガティブな意見のほうが情熱的にうるさい。

 

文化とは方針ではない、物や行事や言葉でもない。行動だ。

何でも許可が必要を必要とする環境は、何も自分で考えない文化を作る。社員を子供扱いする必要はない。

書き物が格式高くある必要はない、あなたらしく正直であればよい

 

 

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢　健二,松永　肇一,美谷　広海,祐佳　ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (32件) を見る
 

 

Developer Summit 2014にいったときのメモ

memo report
２日とも行ってて、聞いたことひたすらメモってたのでその供養。 ・公開分のまとめはここからみる http://codezine.jp/article/detail/7640 ・気になったキーワードとか プロビジョニングツール。pupet、chef、ansible コンテナ作るやつ。Docker モバイルクロスプラットフォーム開発できるXamarin ゲームのUnity3D a developer role focused on testabilityのSET、a role that puts testing firstのTE。開発するためのテストなのか、品質のためのテストなのか。 「小さなチーム、大きな仕事完全版」「リーダブルコード」は読んでなかったので読む。あと「経営戦略全史」面白そうだった。 SSLってなんだっけ・・・ OpenStackとCloudStackは結局どっちがいいんだ Kinect進化してる。Oculus RiftはUnity用のSDKがあったりする。 ドメイン駆動設計をちゃんとやることの難しさ。ちゃんとやったことで得られるメリット。 ・以下は自分のメモ。見なおすかはぶっちゃけ微妙。 ・2/13日分 ◯サーバプロビジョニングのこれまでとこれから（宮下剛輔） pupet chef ansible Infrastracture as Code 　サーバーの状態を定義して実行すると用意してくれる 　冪等性を有する Test-driven infastructure テスト駆動インフラ 　インフラを記述したコードを書く、それをテストする 　serverspecはインフラの状態をテストするためのツールではない、 　インフラの状態を記述したコードをテストするためのツール 　＞違いがわからん インフラCI Immutable Infrastructure 　動かないサーバーに手は入れない、 　新しく用意したサーバーに切り替える。 　変更に伴うトラブルが起きにくい 　よって継続的改善がしやすくなる 　The Twelve-Factor App 　IX. Disposability 　Immutableにできないところはどうするのか 　　ケース・バイ・ケース Contanir Base Deploment 　単機能・軽量なVM 　コンテナをまるごとアップロードして差し替える 　→Docker 　Iaas上じゃなくてもイミュータブルインフラにできる。 　Mesos/YARN等との組み合わせで自動的にリソース配置を最適化できるようになるかも Orchestration 　コンフィグレーション＋単一のサーバで完結する 　　ApacheやNginex 　オーケストレーション＝複数のサーバ 　　ロードバランサにノード追加 　　MuninやMagiosへのノード追加 　　アプリケーションデプロイ 　旧来のオーケストレーション 　　イミュータブルではない 　　サーバの増減が頻繁でない 　　Command&Contraoll 　新しいオーケストレーション　 　　イミュータブルな世界 　　サーバの増減が多く発生 　　Autonomy、自立強調する 　Serf 　　ロードバランサが自動でサーバを組み込む 　　機能　ノードのクラスタリング 　　　ゴシッププロトコルベース 　　　イベントプロパゲーション 　　オーケストレーションをSerfにまかえることでコンフィグレーションがシンプル これから 　テスト駆動インフラ 　　BootstrappingにDocker 　　Pupput、Chef 　　Serverspec 　　Mesos/Yarn 　　SERFでオーケストレーション　 ◯エンタープライズとHtml5 Html5が作り出す新たな世界 　Html5認定試験 　可視化技術は限りなく進歩する 　　頭に思い描くものを可視化したいというものも含む 　KendoUI 　Nvidiaのアクセルレーター 　Creative+ITの能力が圧倒的な優位性を作る 　Webプログラミング、Webデザイン、サーバーのスキルの融合 フロントエンジニアに対する企業のスキルニーズの分析 Html5によって 　デバイスや言語の技術的なインパクト 　誕生した市場と、淘汰された市場、 　ついていくひと、置いて行かれる人 　DENAの例 　　フロントエンジニア（ECサービス 　　　Html5が望ましいスキル、にある 　　フロントエンジニア（ソシャゲ 　　　Html5を使用している、と明記 　　　フォトショなどの操作が、望ましいスキルにある。 　どういうスキルが理想になるのか 　　システム＋デザイン＝フロントエンジニア 　「機能的なものが美しいのではない、美しいもののみ機能的である」（丹下健三 Html5がSIに与えた衝撃、エンジニアは何を学ぶべきか テクノロジとしてのHtml5 　Html5はパラダイムシフトである ムーブメントとしてのHtml5 　実現方法の変化 　　WebブラウザとJavascriptの進化 　　ソフトウェアアーキテクチャの変化 　ユーザビリティの変化 　　マルチデバイス 　　アクセシビリティ 　プレイヤーの変化 　　電子書籍のフォーマットに採用 マイクロソフトが起こした破壊とは 　ソフトウェアライフサイクルの考え方の変化 Appleショックは何を与えたのか 　プラグインベースRIAがなくなっていく 開発プロセスツールの不在 　HTML5はプラットフォーム側から始まった プラットフォームへ依存しない開発手法 ツールの選定 　Grunt,YEOMAN 　VS、SENCHA、Wijimo、ColdFusion ミドルウェアとしてのWeb標準への理解 エンタープライズ特化のHTML5カンファレンス Html カンファレンス　2014でぐぐるのおすすめ ◯ビジネスアプリケーションとつながる「Heroku1」のご紹介（相澤歩） 　Force.com CLI 　Force.com Client Library 　　gem dotenv 　Heroku Connect ◯社内システムの構造と設計、実装のはなし（田籠聡） Dev Of Ops, by Ops, for Ops 社内システムほど他システムとの連携を考える 社内システムではJSONAPIを使う WebAPI制限 →トラフィック、レスポンスタイムへの負荷のせい OpenWebAPI 　コストは誰が払うのか 　互換性は 社内システム 　機能＞性能 　Long Life Cycle 　TargetUser:自分 何が問題か 　情報と権限の分断 　情報と機能の冗長化 　UXの欠如 　自動化の障壁 　全部入り：アップデート不可能 　社内システム連携 　　DB直接接続 　　SOAP 　　CORBA 　　SOA 　　RPC 社内システム連携をシンプルに 　権限、分断を最小限に 　機能、情報には複数の参照方法 　モジュール化 　　単機能システムを連携させる 　　アップデートが容易な状態を保つ 社内システムほどほかシステムとの連携を考える 　機能をAPIとして公開する 　API互換性 　　プロコトル 　　データ構造 　　意味の一貫性 　　クライアント要件の普遍性 プロコトル 　IDL 　SSH 　HTTP,JSON 優先度ハック 逆優先度ハック 　今いらないなら後でやる 必要なところから必要な時にやる アーキテクチャの割り切りが開発・運用を加速する 開発・運用の前提がアーキテクチャをシンプルにする ビジネスへのインパクト 　社内システムほど試しやすい場はない 　顧客は自分 ◯iOSにAndroid、百花繚乱モバイル開発環境を比較する（細川淳） 普通の開発環境 　Android 　　Java 　　AndroidStudio/eclipse 　IOS 　　Objective-c 　　Xcode 　純正のメリット 　　最新機能に対応している 　　情報が豊富 　純正のデメリット 　　環境・言語の強制 　　それ以上のものは提供されない 　Html5+javascript 　　例 　　　PhoneGap 　　　Sencha Touch 　　　Titanium 　　利点 　　　人を集めやすい 　　問題 　　　技術者のレベル差が大きい 　　　チューニングに長けている人と、そうでない人の差が激しい 　　Webサービスのモバイル展開におすすめ 　　Sencha Touchがおすすめ 　Script+Frameworl 　　例 　　　Python+Kivy 　　　Ruby Motion 　　　Ruboto 　　　　Android用 　　　Adobe 　　利点 　　　LL言語を使える 　　　Flasherが活躍できる 　　問題 　　　AdobeAirは遅い気味 　　　Python/Ruby 　　　　Ios/Android両対応しているFrameworkが存在しない 　　WebAPI経由のアプリなどにおすすめ 　　AdobeAir 　　　Flasherが喜ぶ 　Mono 　　例 　　　Xamarin.iOS、Xmarin.Android 　　　Unity3D 　　利点 　　　.Net Frameworkが使える 　　　C#が使える 　　　Unity3D、３Dゲームに向いてる 　　問題 　　　.NET Framework 　　　Xamarin、GUIがネイティブ 　　　UnityのGUI、NGUIとか使う（癖ある 　　一般的なアプリにはXamarinにおすすめ 　　ゲームにはUnity3Dがおすすめ 　Naitive 　　Delphi/C++Builder/Firemonkey 　　例 　　　Nativeである 　　利点 　　　IOS/Android双方ともNativeになる。速い 　　　OS APIにシームレスにアクセス 　　　Firemonkey 　　　　GUIも１ソースで作れる 　　　　２D/3D対応 　　　　DIPフリー 　　　　Style機構 　　問題 　　　AndroidではNaitveであることは推奨されない 　　　Delfi 　　　Styleの調整（PixelPerfect 　　　IDEがWindows専用（Windows On OsX 　　一般的なアプリにおすすめ 　一般的なアプリには 　　Xamarin 　エンターテイメント 　　Unity3D ◯成功と失敗の狭間に横たわる2つのマネジメント（中村洋） 期待マネジメント 　関係者が互いに持っている期待を明らかにし、適切に調整する モチベーションマネジメント 　関係者のやる気を安定して目標に向かうようにする なぜ今この話か 　意思決定が遅れると置き去りになる世界 　単なるタスクではなく、課題の発見から始める 　偉い人が全てを知っているわけではない 期待マネジメントとは 　「ここまでやってくれるはず」というディスコミュニケーション 　ドラッカー風エクササイズ 　　１．自分は何が得意なのか 　　　プログラミングやテスト、積極性とか自分の武器 　　２．自分はどうやって貢献するつもりか 　　　得意なことで貢献するには、ゴールを理解している必要がある 　　３．自分が大切に思う価値はなにか 　　　家族お金キャリアコードなどのこだわり 　　４．チームメンバーは自分のにどんな結果を期待していると思うか 　　　お互いの期待を表明してすり合わせる 　誰と期待をすり合わせるのか 　　関係者全員 　一度やればOKか？ 　　ずっと一緒とは限らない 　　定期的な確認がいる 　事例 　　顧客との期待マネジメント 　「言わなくてもわかってくれる」はない 　　計測できるもので見せる必要がある モチベーショマネジメントとは 　モチベーションの特性 　　何気ない一言で乱高下する 　人によってトリガーが違う 　周りは手助けできるだけ、自分自身でマネージメントするしかない 　成長しやすい土壌を作る　 　自分の調整と相談、無理なときにはすっぱり諦める 　日によってパフォーマンスが違う、しかし、良いプレイヤーは不調な時期が短い 　褒めるのではなく一緒に喜ぶ 　その先にある光景を語る 　若手のチームで頻繁なふりかえり 　　Good!を出しまくった 　成功体験が少ないという問題 　事例　　 　　指示待ち 　　自分たちでやることを考える 　　WHYから始めようより、ゴールデンサークル。 　　　Why, How、What 　　まずは少しだけやってみる 　　　自分たちで改善できるようになる 　　客の顔が見えない 　　　組織の外にロールモデルを求めてもいいのでは まとめ 　期待を表明しあうということ 　関係者のやるきを目標に向かわせること 　Actionしよう！ 　　１，周囲への期待を明らかにしてみてください。周囲からの期待をきいてみてください。 　　２，自分を含めたメンバーそれぞれのモチベーションの源泉を考えてみてください ◯Mobageを支えるテストエンジニアリング（中川勝樹） Mobage Open Platform 　モバゲでゲームを公開できる仕組み QAチーム立ち上げ背景 　プラットフォームのグローバル展開 　大規模システムの拡張とリファクタリング 　デリバリーのスピードを落とさない 　検証属人性の解消 方針 　Endo-to-Endテストを確立する 　テストを徹底的に自動化する 　テストしやすい環境を提供する テストしやすい環境 　単体テストのREDが消えない問題 　リリース頻度・速度・影響範囲のバランス 　テスト時間のコスト問題 　CIの必要性 なぜ独立したチームにしたか。 　横串チームによる、戦略的横展開 SWETってなにか 　Software Engineer in Test. Google Testing Blog How Google Tests Software(書籍 　SET 　　a developer role focused on testability 　TE 　　a role that puts testing first SETs primary focus is on the developer DeNA SWET = SET + TE 　Developer Productivity 　Quality Assuarance SWET Group Mission Statement 　Keep the quality of Platform 　Improve the quality and productivity of Platform エンジニアとして 　テスト対象の開発が行えること 　テスターではなく、テストエンジニアであること SWETの仕事とは 　サーバーサイトテスティング 　クライアントテスティング テスト戦略 　誰がテストをするのか 　　デベロッパーテスト 　　受け入れテスト 　どんなテストか 　　単体テスト 　　結合テスト 　どうやってテストするか 　　ブラックボックス 　　ホワイトボックス 　　グレーボックス 　何をテストするのか 　　機能テスト 　　非機能テスト WebAPIのテスト 　HTTPとJson 　グレイボックスフィクスチャ 　　DBやキャッシュの状態を操作したりする 　特定のターゲット 　　ローカルDNSを使用する 　特定ドメインのクライアント Web/mobileアプリのテスト 　HTTPとUI 　SeleniumWebDriver 　エージェント切り替え 　特定ドメインのクライアント 　ページオブジェクトパターンを使用せず、ドメインエージェントパターン的なことをしている 　モバイルエミューレーション クライアントSDK 　SDKを使ってテスト用のアプリを作る 　それをテストする 　UI自動化 　複数デバイスサポート 　テストケースの一貫性 　　Calabash 　　Appium 結合テスト 　通知機能のテスト マルチセッション 　ゲームとユーザーで違うテストクライアントが使用できるようにしておくことで、結合テストがしやすくする ◯「ITエンジニアに読んでほしい！技術書・ビジネス書大賞」LT大会（白石俊平/高橋征義/吉田健吾/和田裕介（選考委員））（角征典） 経営戦略全史 小さなチーム、大きな仕事完全版 リーンスタートアップ無駄のない企業プロセスでイノベーションを生み出す アジャイルサムライ なぜ、システム開発は必ずモメるのか リーダブルコード ・2/14日分 ◯Webの現在過去未来（竹迫良範/和田裕介/宮川達彦） OpenID 認証と認可 ネイティブアプリ 　プラットフォームにお金払えば、純粋にコンテンツだけで勝負できるという世界 電子書籍 　個人デベロッパーが直接書籍を販売できる Iosのニューススタンド デバイスやリテラシーを選ばないメール プラットフォームロックインのサービス github等を使った書籍の執筆とか オライリーが実験している書籍作成のインタラクティブ化 ◯暗号破りに新たな攻撃！進化する脅威に対抗するためのWebサイトセキュリティとSSLの進化（林正人） 電子証明書 　SSLサーバ証明書 　コードサイニング証明書 　セキュアメールID SSLサーバ証明書 　SSLを支える技術 　　Webサーバ運営団体の実存性の証明。公開鍵暗号。Ex(RSA,ECC,DSA 　　暗号鍵 　　暗号の世代交代の必要性 　　暗号の世代交代で考慮すべきこと 　　　暗号強度とユーザビリティのバランス 　具体的なアクション 　　SHA-2の導入 　　！RSA(SHA-2)を利用するウェブ管理者はSHA-2にあと3年以内にSHA-2への移行を済ませなければいけない 　ECCについて コードサイニング証明書 　！RSA(SHA-2)を利用するウェブ管理者はSHA-2にあと2年以内にSHA-2への移行を済ませなければいけない Webサイトへの攻撃 　被害拡大中 　分業化専業化により、攻撃者も高度化 　さまざまな攻撃手法 　Struts2の脆弱性の事例、SQLインジェクションの事例 　脆弱性のギャップ 　　安全性についてチェックしたことがある企業は多くない 　脆弱性の対策 　　各工程でセキュリティを考慮する ウェブアプリケーションファイアーウォール 　プロクシ的に間にいて防御する ◯アプリケーションエンジニアのためのクラウドインフラ再入門（司会：吉田雄哉/輿水万友美/曽我部崇） クラウドを使う開発が多くなり、アプリ開発者は低レイヤーを学ぶ機会が減っている OSSクラウドを駆逐するソフトウェアを通じて 　クラウドの基礎的な理解 　クラウドを活かすソフトウェアの設計 OpenStack 　ブラックボックスは怖い 　PrivateCloudをうまく使うと便利でお得 　できること 　　AWSみたいなインフラを構築できる 　特徴 　　OSS 　　コンポーネント 　使うメリット 　　クラウドサービスの設計理念がわかる 　　スケールアウト性能の高いソフトウェアの作り方がわかる 　　プライベートクラウドを構築できる 　事例 　　プライベートクラウド 　　　Cisco、Paypal、GREE 　　パブリッククラウド 　　　IO.Cloud、RackSpace、HP、GMOインターネット 　始め方 　　VM上のUbunt,CentOSとかにインストール 　　devstackを使う 　最新動向 　　Heatコンポーネント 　　　複数のインスタンスで構成されるシステムをtemplateで一括deploy 　　Celiometer 　　　課金に必要な利用状況を集計する 　　　プライベートクラウドでも状況を知るのに使える 　　OpenComputeProject 　日本OpenStackユーザ会 　　勉強会 　　ハッカソン 　　コードリーディング CloudStack 　特徴 　　OSS 　できること 　　AWSのような仮想インフラの作成 　CloudStackの機能 　　AWS　EC2/EBS/S3とほぼ同様 　アーキテクチャ 　　管理サーバを中心とした集中管理 　日本CloudStackユーザー会 DeNAにおけるゲーム以外の新規事業の立ち上げ方（沖津貴智） もの作りの進め方 　スクラムの守破離 スクラムの基本を忠実にこなすだけだとコストが高い 　コストの大きい部分 　　バックログ、バーンダウンチャート、スプリントプランニング 　工夫してみたこと 　　専任のスクラムマスターをやめる 　　タスクの粒度は荒く 　　バーンダウンチャートは排除 　　タスク管理は各チームやりやすい方法 　少人数体制 　　プロディーサ1名 　　エンジニア1名 　　UI/UXデザイナー1名 　座席 　　チーム単位で座席おく 　結果 　　各人が考えて行動している感じが強くなった 　　少人数かつ裁量を増やすことで帰属意識 　　デイリースタンドアップ、プラニングと振り返り兼ね、PDCA早い 　人が増えたら 　　進捗遅延、意思疎通など、従来通りの問題が起きてくる ものづくりアンチパターン 　一生懸命考えたけどユーザは使ってくれない 　ヒアリングしてみて必要そうだったから作ったけど使ってくれない 　ユーザは本当は何がほしいのか 事例 　チラシル 　　練馬の主婦を集めて、プロトアプリをインストールしてもらい、リモートでヒアリング 　アプリゼミ 　Peko 　※Facebookログインする？って聞いても半分はNoというが、実際使わせてみると8割ほどは使用する UserTesting.comおすすめ 技術面の話 　サーバーアプリケーション構成 　　リードエンジニアが好きに使いたいフレームワークやミドルウェア 　通信プロコトル 　　JSON-RPC over Http 　　JSON over Http 　インフラ 　　自社のデータセンター 　　コスト優位な部分ではAWSも使用 　スケーラビリティ 　　新規サービスはあたるかどうかわからないので、スモールスタートしたい 　　どんな小さく始めるとしても確保は必須 　インフラの基本構成 　　疎結合＋多重化 　サービスの規模によって要検討 　　データベースの垂直分割 　　データベースの水平分割（シャーディング 　インフラ特化型の共通モジュール 　　Baranモジュール 　さらなる高速化 　　Mbaas 　　Parse,Google Mobile Backend Starter 　Github Enterprise 　　全員が各リポジトリをWatchしてる 　　エンジニア・デザイナー間コミュニケーション 　　　画像リソースやりとりをGithubEで 　IOs?Android? 　　まずどちらかのみ注力し、当たりそうならもう片方もやる 　対応IOS 　　最近はIos7専用多い 　対応Android 　　Android2.3以降サポート 　Iosよく使われるライブラリ 　Androidよく使われるライブラリ 　通知 　　ユーザ間のコミュニケーションスピードが年々早まっている 　分析用ロギング 　　かなり重要 　　アナリティクス、Flurry 　分析プラットフォーム 　ログ出力のポイント 　　APIアクセスログ 　　アプリ起動ログ 　　画面ごとの表示ログ（画面遷移、離脱ポイント 　　サービスごとに必要なポイント（入会とか 　プロモーション 　　リリースしたけど何も起こらない 　ある程度ユーザを流入させて数字をみる 　FacebookAd/TwitterAdが比較的使用しやすい 　FacebookAd広告クリエイティブ 　　キャラ系、人物系、アプリのUI系 　　事例だとUI系がうけよかった 　オフラインプロモーション　In US 　　飲み屋でおねーちゃんにアプリを進められる 一年たってみて 　余計なこと考えずに問題に向かう 　ひたすらフィードバックと改善をする 　銀の弾丸はない ◯モーションセンサーの現状と2014年の予測（中村薫） なぜセンサー 　センサー価格の低下 　Web,モバイルに続く価値 デジタルサイネージ 空中ディスプレイ 現実世界へのインタラクション 　階段＋マッピング＋Kinect さまざまなセンサー 　全身 　　Kinect 　　Xtion/Carmine 　　KinectV2 　指先 　　Creative Senze3D 　　Leap Motion NUIの先駆け Creative Senze3D 　開発会社がAppleに買われた 2014年度の予測 　新しいデバイス 　　ストラクチャーセンサー 　　MIO 　センサーの内蔵化が進む 　　Leap Motion 　　Intel Perceptual Computing SDK 　３Dプリンタのモデル化に内蔵センサーとかが生かされる未来？ もっと未来 　モバイル 　　IOｓやAndroid対応のセンサーが発売される 　Web 　　Webやクラウドと背サーの連携が進んでいく 　ウェラブル 　　センサー、モバイル、ウェアラブルの融合 　　Meta Pro 　　Oculus Rift 出力装置の進化 　入力が３Dなら出力も３Dにする Oculus Rift Demo 　Unity3Dで動かせる ◯Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所（吉村総一郎） ニコニコ生放送をScalaで書き話している話 なぜ書き直すのか？ 　技術的夫妻 　　PHPが300万行 　　コピペ１万 　　潜在的不具合４５００ 　　循環複雑度６００ 　　リフレクション多用しgrep不能 　循環ド複雑度６００度 　　終盤のジェンガ 　　通常は50でテスト不可能 なぜこうなったのか？ 　要件と締め切り優先で、内部品質やプロセス品質をおろそかにしている体制 　人員が増えていったが、パッチワーク的修正が大量 このような状況に対して打ち出した緊急対応 　各人のタスクを見える状況にした 　いらない機能を削って保守コストを下げる 　個人開発から開発体制へ移行してチームで開発をする 　長期案件、突発対応、改善活動の３つのチームに分割し、安定して改善活動を行う 3ヶ月間の対応の結果 　休出ストレス減った、ストレス減った、離職減った ニコ生２の開発 　スケーラブル 　安定性・フォールトトレラント性 　保守性・拡張性 　パフォーマンス プロトタイプ作成をしながら２週間に一度ショーケースで紹介 　１０月で初期リリース、１２月で大規模配信 Play2/Scalaでの大規模開発 なぜScala 　Java,Scala,PHP,Ruby 　保守性の観点から性的型付け言語 　プロトタイプを作ったメンバーはJava/Ruby/関数型色々使えたのでScalaでも問題なし PHPしか知らない人がScalaをやるにあたってネックになる知識 　　アルゴリズムとデータ構造 　　　PHPにはarrayしかないとか 　　　対策：勉強会、プログラミングコンテストチャレンジブック 　　純粋関数型プログラミング 　　　無理に適用しない 　　　ベターJavaとして使う 　　ValとVar 　　　Valを徹底 　　　可変コレクションは扱わない 　　　徹底しても困らない 　　　サーバーでメモリリークが発生しなくなる 　　Implict 　　　ライブラリ層を除き利用しない 　　　Implicit converterを使うと負債になりがち 　　　ImplicitがあるとPullRequestのレビューでわかりにくい 　　並行プログラミング 　　　Actorのトラブル解決で必要 　　JVMとJavaライブラリの仕組み 　　　やりながら学ぶ 　　　１理詳しい人がいればなんとかなる ニコ生２のアーキテクチャ 　インフラメンバーにデイリースタンドアップに参加してもらった 　　コミュニケーション重要 　　インフラの制約などを確認 　クラウドではなくオンプレミスという選択 　　IOパフォーマンス 　　費用 　　社内方針として 　　　人材確保と教育が問題 　DBの水平分割と垂直分割 　　MySQL 　　水平分割 　　　IDの中にシャードIDやデータタイプを組み込んで、シャーディングしやすくしている 　　　Instaram,Pinterest,TwitterのSnowflakeなどを参考にしている 　２つのキャッシュ 　　中央RedisとローカルRedis 　冗長化方法 　　MySQLはMHA 　　RedisはSential 　アプリケーション構成 　Websocketアプリ１インスタンスで５万ユーザーの視聴管理を実現 　　NginxとNetty 　　REST APIからWebsocketを利用することで接続コストがさがった 　　パフォーマンス測定 　　　Gatling 　　　Node.jsのプラグインを自作した 　ドメイン駆動設計を実施するために徹底したこと 　　ユビキタス言語 　　モデルを使って議論する 　　レイヤードアーキテクチャ 　　正しいモジュール化を行い、変更時に読まなきゃいけないコードを減らす 　　エンティティと値オブジェクトの使い分け 　Play2はDDDを実践するのに良いフレームワーク 　　CoCがきつくない 　　マルチプロジェクトで依存関係を作れる 　　CaseClassが便利 　エリック・エヴァンスのドメイン駆動設計に入る前に読んでもらいたい本が多い 　　Youtubeに上がっているDebLovで津元さんがDDDを解説した動画が素晴らしい 　ユビキタス言語 　　近い座席、会議 　DDDを実践する価値 　　DDDではないコードの例を考える 　ユビキタス言語が導入されると、同じ言葉で会話できる 　コードと要件について話している言語の乖離が少なくなり、リファクタ性能が上がる 　　ドメイン層 　アプリケーションの運用とチーム開発 　Capistranoによるデプロイ 　　Playの設定のテンプレート 　コード規約 　　Scala Guide / Effective Scala 　開発環境 　　Intelij Idea Ultimateに統一 　JenkinsでCI/CD運用 　　検証期間の工数を削減できた 　Play2の問題点 　　Sbtが遅い 　　Play2のテンプレートが、コンパイル遅く、文法がデザイナーにやさしくない 　　objectとtraitがテストで困る スクラムの導入 　ウォーターフォール開発、アジャイル開発 　アジャイル導入までつらみ 　　ガントチャートが好き 　　啓蒙活動 　　マネジメント問題の根本はアジャイルやウォーターフォールが関係ないことが多い 　スクラムはリーダーを育てるのに素晴らしい開発手法 　　会議体が固定 　　JIRA/GreenHopperなどのツール 　　書籍が充実 　　　アジャイルサムライ、アジャイルな見積もり、ドラッカーのマネジメント 　スクラム開発の課題 　　コミニュケーションコストが高い 　　メンバーの要件定義の能力が身につきにくい 　　要求や要件が深いコンテキストがドキュメントにまとまることがすくない 　ニコ生のスクラムで重要していること 　　ユーザーの要求理解に対して時間をかける 　　ストーリーポイントを小さくする 　　密なコニュニケーションのストレスを減らす 　　スクラムマスターが常にプレイングマネージャーであれるようにする 　　ゆとりを持った開発計画 　　規格と相談するときには、不確定な時期と優先順位と一緒に持ち込む 　　インフラチームやほかチームおの合同作業は共同バッファを用意する まとめ 　Play2は大規模でも使える 　Play2はDDDしやすい

pythonのflaskで自分用アップローダを作った話

python flask

ニンテンドー 3DSありますよね。
あれの新絵心教室っていうゲームで、書いた絵を写真として保存しておけるんです。
その写真を取り出してネットにあげようとおもうと、SDカードを取り出してPCにつなげてコピーしてアップロードしないといけないんですね。
これがめんどくさい。


3DSのブラウザから直接ネットにアップロードして、
PCから同じ場所みてその画像を取得できるようにしたいと思いました。


そこで自分用の3DSのブラウザで使えるアップローダを作りました。



こんな感じ。なお実物は私しか知らない場所にありますのでご了承ください。
https://github.com/arvelt/flask-fileupload-sample


作ってから調べたらやはりすでにあったんですけど全く問題ありません。


はいでは作ってみてわかったことや気になったコトなど書いていきます。


○以下ハイライト
・flaskすごい。pythonのsinatraみたいなやつ http://flask.pocoo.org/
・コントローラーとテンプレートをさくっと提供してくれて楽
・os.pathがすごい
・3dsブラウザのUserAgentは「Nintendo 3DS」
・gitで空のディレクトリを保持したいときは.gitkeep入れるといい
・flask.url_forを使うと欲しいurlはだいたいとれるのでちゃんとドキュメントかソースを読むのがおすすめ
・デプロイはちゃんとわかってないとめんどくさい


○以下参考にした場所とか
http://flask.pocoo.org/docs/quickstart/
公式ドキュメントのクイックスタート。ここ読むとだいたいはわかる。ちゃんとFile Uploadsの項目があってありがたい。


http://memo.yomukaku.net/entries/195
空のディレクトリを保持したいときは空の.getkeepをおいておくらしいという話。


http://zafiel.wingall.com/archives/7513
flaskアプリをapache上にデプロイするときのやり方について。自分でやってみるとこのパスはどう書くんだよってなりがち。



○気になること
・モデル
DBとマッパーはpeewee+SQLiteだと小さく手軽にやれそう。https://pypi.python.org/pypi/peewee


・python
python自体をあまりわかってないことに気づいた。文字コード。日付操作。型とか。


・pythonエコシステム
python自体以下略。virtualenv、setuptool、pip、pep8とかよくわかってない


・Paas
flaskはかなり手軽なのでなにかさっと書きたいときによさそう。そこでさっと書いたやつをぱっと公開するためにPaasに載せる方法を調べておきたい。

Windows8を新規インストールしたときに行うことメモ

windows memo

http://arvelt.hatenablog.com/entry/2013/09/24/110048
これに追加で8系のときに必要な設定。
デスクトップで使用するために変える。


１．起動したらスタート画面じゃなくてデスクトップを表示するようにする。
http://www.atmarkit.co.jp/ait/articles/1302/22/news054.html


２．アプリ起動でスタート画面までいかないと行けないので、デスクトップにランチャーおく。Orchis
http://www.eonet.ne.jp/~gorota/


３．ロック画面を表示しないようにする。
http://windows8.a-windows.com/login.html

Unity入門１

unity javascript

Unityを触っていきます。

できたもの。リンクはあとで変えるかも
https://dl.dropboxusercontent.com/u/19360039/block-ball1/block-ball1.html


・できたこと、わかったこと
Unityではシーンという単位でゲームを作る。
ゲーム内に存在する全ての概念を、ゲームオブジェクトとして扱う。
ゲームオブジェクトに挙動や設定やスクリプトを、コンポーネントとして追加していく。
カメラとライトが必ず必要。
オブジェクトに物理的な特性（硬さ、重さ、重力の影響）を与えたい場合はRigidbodyコンポーネントを使用する。
jsの場合、コンテキストメニューのcreate-javascriptからスクリプトを作成し、オブジェクトにドラッグすると紐付けできる。start()は開始時に１度、update()は毎フレーム呼ばれる。gameObject変数が自分自身を指す模様。変数を関数スコープ外で宣言することで、インスペクターUIで直接設定できるようになる。
反射等はPhysic Materialコンポーネントで設定できる。
ユーザー入力はInput Managerによって抽象化されている。Input.GetAxisRaw("Horizontal")で左右、Input.GetAxisRaw("Vertical")で上下が取得できる。それぞれ-1～1が返る。
Coliderが設定されたもの同士が衝突するとOnCollisionEnter()が発生する。その中でDestoy(gameObject)と書くと自分自身が消える。ブロックにこのスクリプトを設定すれば、ボールが当たったときに消える。


参考にしたもの
http://japan.unity3d.com/developer/document/tutorial/my-first-unity/01
公式にあるチュートリアル。
惜しむらくは全四回のうち第一回しか公開されていない。


http://dotinstall.com/lessons/basic_unity/24624
http://kusogamer.blogspot.jp/2013/05/unity_16.html
衝突検知はここから。