ffmpegを使用して動画をH.264形式にエンコードするにあたってのffmpegインストール方法
ffmpegのみで動画を変換した場合、動画がブラウザで表示されなくなる。
yasmのビルド/インストール
wget http://www.tortall.net/projects/yasm/releases/yasm-1.3.0.tar.gz tar xvfz yasm-1.3.0.tar.gz cd yasm-1.3.0 ./configure --prefix=/usr/local make make install
nasmのビルド/インストール
wget https://www.nasm.us/pub/nasm/releasebuilds/2.13.03/nasm-2.13.03.tar.bz2 tar xjvf nasm-2.13.03.tar.bz2 cd nasm-2.13.03 ./autogen.sh ./configure --prefix=/usr/local make make install
x264のビルド/インストール
git clone git://git.videolan.org/x264.git cd x264/ ./configure --enable-shared --disable-opencl --prefix=/usr/local make make install
ライブラリの再読込/PKG_CONFIG_PATHのパスを通す
# ライブラリの再読込 ldconfig # PKG_CONFIG_PATHを通す export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
ffmpegのインストール
wget https://ffmpeg.org/releases/ffmpeg-3.4.7.tar.bz2 sudo tar jxf ffmpeg-3.4.7.tar.bz2 cd ffmpeg-3.4.7 ./configure --enable-shared --disable-opencl --prefix=/usr/local make make install
仲良し4人で湯河原に開発合宿に行って最高だった
事前準備
開発合宿のしおりを用意した。 これがかなり良くて、しおりさえ見たら何するか大体わかったとのこと。
実際のしおりはこれ hiragram.kibe.la
あとは各自事前にやること決めてた
当日
10時半前ぐらいに品川駅集合して湯河原に出発。 1時間ぐらい電車に乗っただけで湯河原着くのすごい。
湯河原に到着したの12時前かつお腹空いたので予定通りマグロ丼食べに鮪屋へ
その後タクシーで宿に行き、合宿開始。 会議室は4人なのにめっちゃ広かった。
ホワイトボードがあったり、腰のためのクッションが豊富で腰痛持ちには本当にありがたかった
余談だけど宿から徒歩30秒のところにコンビニがあるの最高
作業開始しようと思ったけど事前にマリオパーティーがプレイできるか確認したりしてた。 1ゲーム終わったらだらだら話しながら作業してたのに結果的にはめっちゃ捗ってた。
宿はこんな感じ。結構綺麗
18時にはご飯食べた
ご飯食べたらマリオパーティーしたり、
温泉入ったり、お酒を飲みながら作業したり、足湯浸かりながらアイス食べたり各々の時間を過ごして就寝。
2日目は朝起きてチェックアウトしてから個人の発表会した
宿から出てすごい楽しみだったラーメン屋さんに行ったら もう整理券配布終わってて、最短で15時からしか食べれないらしくて諦めた。 本当に悔しい。
代わりに行きたかったパン屋さんに行った。 30分ぐらい並んだけどすごく美味しいパン買えて満足。
次回行くときは整理券獲得してラーメンも食べるし、パンも買って帰ることにする。
なぜだかわかんないけど開発合宿中、作業がめちゃめちゃ捗ったのでこの捗りは行く価値あるわって思った。
守破離を意識すると今よりずっと成長しやすくなる
今までの振り返りをしていた際にふと思ったことについて、言語化していく過程で どうすれば学習が捗るかというのが自分の中で明確になったので書きます。
守破離
修業における段階を示したもの。
- 「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階。
- 「破」は、他の師や流派の教えについても考え、良いものを取り入れ、心技を発展させる段階。
- 「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階。
守破離の例
- 守：支援のもとに作業を遂行できる（半人前） ～自律的に作業を遂行できる（1人前）
- 破：作業を分析し改善・改良できる（1.5人前）
- 離：新たな知識（技術）を開発できる（創造者）
守について
- 新しく何かを始める場合は必ず守から始まる
- ほぼなにもできない/なにも知らない状態
- 基礎/基本的な知識が足りない
守の状態での課題
- 学び方を知らないので学ぶことができない
- なにから学んでいいかわからない
- ついつい簡単そうなものに手を出してしまいがち
- （1週間で話せるようになる英語）
守の課題に対しての解決方法
- いい師匠を見つけて、師匠から学び方を学ぶ
- 一番力を入れないといけないところは いい師匠を見つけること
- 師匠が見つからない場合は知見がある人に オススメの書籍を聞くぐらいはやる
守の時に意識しておくと良いこと
- まずは全体像を掴めるようになることを意識
- 基礎力をつけることを意識
- 素直になる
- 師匠からのフィードバックは素直に受け入れて実行
- 自分の持ってる知識から かなり離れてしまうアレンジはしないようにする
守の時の禁止事項
- 複数箇所から情報を得る
- 色々な人の意見を鵜呑みにして 色々なことに手を出す
- 複数のブログや複数の書籍を読み漁る
- 理解できない範囲でのアレンジ
- 基本がわかってないのにアレンジしたら もっとわけわからなくなる
- わかる範囲でのアレンジは良い
破について
- ある程度自分で仕事ができるようになってるはず
- この部分で非常に成長が止まりやすいところ
破の状態での課題
- 今まで通りやってるだけじゃ成長しなくなってくる
- 業務も今持ってる知識だけでも こなせてしまう状態
- 課題に対してのアプローチ方法が単調になりがち
- ある程度できるようになったので努力することを辞めてしまう
破の課題に対しての解決方法
- 大量のインプットと少量のアウトプットを意識
- アウトプットを意識して、大量にインプット
- インプットした情報から得たエッセンスを 元に色々試してみる（少しだけアレンジ）
破の時に意識しておくと良いこと
- 自己客観視する（周りからの自分の把握）
- 社内/社外問わず、色々な人を見てみるのもあり
- 周りに優秀な人がいないなら転職するのも一つの選択肢
- 徹底的に質を意識
- うまくいってる/いってないに関わらず 振り返りを行い改善
破の時の禁止事項
- 周りを見ずに自分ができると思い込む
- インプットせずにアウトプットすること
- 結果ほぼ何も身につかない
- アウトプットせずにインプットすること
- 学習した結果を自分のものにすることができない
離について
- 自分の中で「なんとなく良い感覚」というものが 備わってくる
- 周りからも頼りにされやすい
離の状態での課題
- 再現性の担保ができない
- 再現性や論理性が求められることが多い
- やり方をうまく人に伝えることができない
- うまくいく理由を説明できない
離の課題に対しての解決方法
- 抽象化、言語化を意識する:
- 本読んだり
- 思ったことをずっとメモったり
- パターンランゲージの本見るといいよ
- 人に教える
- 教えるときに抽象化されたり、言語化されることが多い
離の時の禁止事項
- なんとなくでいいやと抽象化、言語化を諦めてしまう
- 現実的には言語化できないものもあるが、言語化できるものもかなり多い
補足
よくやる間違い
- エンジニアからエンジニアリングリーダー/マネージャーになった際に破や離から始めてしまう
- 職種や役割が変わった時は必ず守から始めると良い
- うまくいってるからって努力をやめてしまう
- 本質理解せずに著名の人のやり方をなんとなく真似る
- ちゃんと理解せずに小手先のテクニックだけを続ける
- それでもある程度の成果は出てしまうから仕方ない部分もある
言いたいこと
熟練者はパターンランゲージというものを知っておくと学びが加速する
汎用性が高くて知ってるとすごく便利
パターンランゲージとは
- 元々は1970年代に「建築家クリストファー・アレグザンダー」が住民参加のまちづくりのために提唱した知識記述の方法
- 過去の成功に潜む共通パターンの言語化
- なんとなく良い、勘、センスの言語化
- パターン:
- どのような状態の時に
- どのような問題が生じやすく
- それをどのように解決すればいいのか
なぜパターンランゲージが必要か
小さく、依存度の低いモジュールにする
なにかがうまくいった経験（状態）というのは様々な背景/事情などの依存が存在している。 - 様々な背景/事情などの依存から切り離し、抽象に落として汎用的に活用できる知識にすることで 課題に対してどんなパターンが有効かという選択肢が瞬時に見えてくる。
小さく依存度の低いモジュールにしたら使いやすいし試しやすい。
パターンを色々な人が試してアップデート
- 他の人たちが解決したものから得られる知見も異なる視点で見やすくなるので他の人の経験を自分の経験に落としやすい
- 他の人の経験を取り込みやすい
パターンをみんなで育てることができる。
パターンランゲージの特徴
- 情報のストックが頭の中にできる （頭の中での再現性の向上）
- 教える、伝えることで人に渡すことができる
- 初学者でも同じやり方をすれば同様の成果を出すことができる
- 複雑なものも簡単に扱うことができる
- 言語化することで複雑な事象を一言で説明できる
詳しくは読んでみよう
パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)
- 作者: 井庭崇,中埜博,竹中平蔵,江渡浩一郎,中西泰人,羽生田栄一
- 出版社/メーカー: 慶應義塾大学出版会
- 発売日: 2013/10/23
- メディア: 単行本
- この商品を含むブログ (8件) を見る
こちらもご覧ください
「エンジニアリング組織論への招待」を読んだ
エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: Kindle版
- この商品を含むブログを見る
この本について
「不確実性に向き合う」というテーマを中心に 様々な知識のもとに、組織におけるエンジニアリングについて いい意味で深ぼることなく、広く書かれている本です。 モダンなエンジニアリングマネジメントの集大成と言ってもいいと思う。
こういった本だと通常は本質を突かずに、方法論などが書かれている だけの書籍が多い中、ここまで本質を突きながらも、 全体の流れとしてここまで筋が通っていて、納得感のある本はなかったんじゃないかと思います。 控えめに言っても名著。
どういう風に読むのがいいのか
この本は全ての章を飛ばさずに最初からちゃんと読んだほうがいいです。
色々なバックグラウンドの方が読んでも近い認識を持ちやすい本なので、この本を何人かで読んでからディスカッションするのもいいんじゃないかと思いました。
どういう人が読むといいか
- スタートアップの経営者、新規事業責任者
- マネージャー（エンジニアリング関わらず）
- エンジニアリングリーダー的な役割をやる人/やったことがある人
この本を読んで得られると思われるもの
- エンジニアがエンジニアリングを行う際に何を考えているかの一部が理解できる
- 様々な知識を得るためのフック
- それぞれのアプローチに至るまでの歴史、背景
注意点
トピック量が多いのと、あまり多く使われない言葉も多く書かれているので、そういった言葉に慣れてない人は 読むのが大変かもしれないです。
個人的に好きなところ
学んできた知識がどんどん繋がっていく感じと言語化されている感じがすごくするので読んでて気持ちいい本
比喩表現も絶妙で納得しやすい話が多かったと思います。
特に最初の方にコミュニケーションの不確実性がもたらす例として書かれている「カレー作りの寓話」が好きでした。
正しく、論理的かつわかりやすい言葉で全体の流れがぶれることなく書かれていて素晴らしい本でした。 とても密度が高い本です。
この本を読んだら次に深掘りするべき言葉がわかるので、 次に何を調べればいいかわかるようになると思われる。
また、読んだらすぐに実践できるものもたくさんあるし、 今後に繋がる部分も多いのでまずは読んでみるのがいいんじゃないですかね。
最高でした。
Android開発をやるときに決めること
Android初心者なので、間違ってることとかあったら教えてください
言語を決める
AndroidはJavaもしくはKotlinを使って開発する必要がある。 今だったら基本、Kotlinを選ぶ。だけどJavaで書きたいとか Kotlinを全然覚えられる気がしないとか、初心者ですとかだったら Javaを選んでもいいのかなーって思ってる。
※正しくはAndroidは他の言語でも書くことは可能だけど、公式でサポートしているという意味ではJavaとKotlinのみ
Rxを使うかどうか決める
RxAndroidを使うかどうか。 結局、スマホアプリは状態を非常に多く持ちやすいので、Observerパターンのようなものの 実装に落ち着きやすいと思っている。 その上で、Rxを使うことでそういった処理が書きやすくなるのかなって思ってる。
GitHub - ReactiveX/RxAndroid: RxJava bindings for Android
DIに何を使うか決める
Dagger2というものが一番多く使われているらしい。 他のもあるみたいだけど、ちょっと調べきれてない。
Android Architecture Componentsを使うかどうか決める
堅牢でテスト性とメンテナンス性に優れたアプリを設計するためのライブラリのコレクションだそうだが、 見た感じ、良さそうな感じする。Androidライフサイクルの管理が楽になりそう。 学習コストは高いみたいだけど、自分がやるんだったら選択すると思う。 学習コスト払いたくないなら使わず書くのもいいと思う。
DBライブラリを選ぶ
基本的にはRealmかOrmaを選択すると思う。 Android Architecture Componentsを使ってるんだったらRoomを選択してもいいような気がする。 よほどパフォーマンスを求めたいのなら、Realm一択かと思われ。
Realm: Create reactive mobile apps in a fraction of the time
https://github.com/maskarade/Android-Orma
最初に何を選択するかによってアプリの実装しやすさがかなり変わってくるので、 ちゃんと選んでおくことをオススメします。
チーム開発をやるときに最初にやること
開発チームを作るときに最初にやっておくことを書いてみる やることってフロー情報とストック情報を置いておく箱を用意するっていうことなんだけど、 あんまりできてなかったりするチームもあると思うので、書く。
- 雑に話せるSlackチャンネルを作る
- ドキュメントを書く場所を作る
- ドキュメントの置き場所を作る
雑に話せるSlackチャンネルを作る
Slackじゃなくてもいいんだけど、雑な会話が簡単にできる状態を作っておくと捗る。 仕事の話も適当に今日のランチの話もその作ったチャンネルで話している状態だと良い。 よくSlackチャンネルを種類別に分けようとかの話になったりするんだけど、 どのチャンネルに発言していいかわからなくなるし、迷って「やっぱり言わなくていいやー」とかに なってしまうので、チャンネル数はできるだけ少なくする方がいいと思う。
なお、GitHubと連携してたり、Botが頻繁に投稿するようなチャンネルとは分けたほうがいいと思う。
ドキュメントを書く場所を作る
なにかしらの情報をストックするための場所がないと、情報がストックされないので、 Wiki的なものを使うと良い。
使いやすくて、書きやすくて使っててストレスが少ないツールを選ぶのがいいと思う。 書くのが苦痛なツールを使ってると書く気がなくなって、書かなくなる。 個人的にはKibelaを使うのがいい。esaでもいい気がする。 また、誰も投稿しないとどういう風に使ったらいいかわからない雰囲気になるので、 最初に自分が投稿しまくると他の人も真似して使ってくれたりする。
ドキュメントの置き場所を作る
文章とかはKibelaとかに書けばいいんだけど、PDFとかその他のファイルとかを貯めたいってなったときに 置く場所がないと誰かのPCのローカルにしか存在しないとかあったりするので、Google Driveの共有とかを 使って、ファイル共有をできるようにしておくと良いと思う。
上記を積極的に使いつつ、周りに啓蒙していくと捗ると思います。
