“SHIROBAKO” [第2クール] - three million cheers.
第2クールは、プリプロダクション段階からのスタートおよび原作付き作品であるというところが第1クールと異なる。 上山高校出身の5人全員が何らかのかたちで同じ作品に関わることになる。新キャラクターが登場。宮森は担当からデスクへ。 （第1クールについては、http://d.hatena.ne.jp/LJU/20150111/p1） 各話概要 第13話 “好きな雲って何ですか？” 宮森、デスクになる。井口さん、総作監に。ナベP、独断専行を注意しつつも承諾。しずか、オーディション参加へ。 第14話 “仁義なきオーディション会議！” しずかオーディション。平岡さん登場。みどりが設定制作として参加。美沙の事務所がCG制作で参加。しずか落胆。宮森、平岡さんからタイタニックを紹介される。 第15話 “こんな絵でいいんですか？” 入社パーティ。安藤さん･佐藤さん参加。各話制作開始。久乃木さん登場。美沙、CG打
![“SHIROBAKO” [第2クール] - three million cheers.](https://cdn-ak-scissors.b.st-hatena.com/image/square/07b01d3f80a1dc0bbd538b4689b94961eecb0c77/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FL%2FLJU%2F20150412%2F20150412172914.jpg)
“SHIROBAKO” - three million cheers.
自分のなかで2014秋アニメ最高作品だったのがこの『SHIROBAKO』。 2クールなので冬も継続して放映中だけど、あまりに好きすぎるので現時点で一旦感想を書いておきたい。……先日の第13話見たら2クール目も密度濃くなりそうだったので、1クール分について今メモしとかないとあとで書くこと飽和しそうってのもある。 もう誇張なしに各話最低3回以上ずつ見返してるぐらい好き。 概要 アニメ制作会社で働く人々を描いている作品。仕事群像物、といった感じ。 本数過多で百花繚乱な最近のアニメ業界、その制作現場が舞台というところがもちろんまず大きく興味を引くポイント。アニメ作品はこういう人たちがこういうふうにつくってるんだ、っていうのが強いデフォルメほとんどなしで実態に沿って描写されてる。「監督」「演出」「撮影監督」「作画監督」「原画」「制作進行」…etc といったさまざまな担務はいったいどのようなことをおこ
GitHub - twada/licensify: Browserify plugin to prepend license header to your bundle
/** * Modules in this bundle * @license * * licensify: * license: MIT (http://opensource.org/licenses/MIT) * author: Takuto Wada <takuto.wada@gmail.com> * contributors: Okuno Kentaro, Ayumu Sato, Denis Sokolov, yudppp, Daijiro Wachi * homepage: https://github.com/twada/licensify * version: 3.1.0 * * convert-source-map: * license: MIT (http://opensource.org/licenses/MIT) * author: Thorsten Lorenz <
フロントエンド開発の３ステップ（npmことはじめ） - Qiita
スライド 当記事は以前勉強会でLTしたものです。 スライドは下記にあります。 フロントエンド覚えること多すぎ問題 モダンなフロントエンド開発で、入門記事を探そうとすると、 まずwebpackやTypeScript, Babelによるビルド環境構築から始まる記事が多くヒットします。 ですが、Node.jsの初心者がいきなり複数のツールを習得しようとすることが 挫折の原因になっていると感じています。 ですので、まずNode.jsをインストールした直後から、必ず使うことになる、 npmの機能をまず覚えておきましょう。 フロントエンド開発で覚えるべき３つのコマンド 以下の3つだけ覚えておきましょう。 npm init npm install npm run これだけ覚えれば、ひとまずフロントエンド開発を進めることができます。 完璧なワークフローを構築するのは、書いているアプリが大きくなってきてから
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
技術書の読書法 | 【青】新婚でジョホールバルへ教育移住した最高技術責任者（CTO）のブログ
【青】新婚でジョホールバルへ教育移住した最高技術責任者（CTO）のブログ幸せの青に包まれた家庭を築く為、結婚前から海外移住を計画し新婚で教育移住を実行。WebとITを活用して仕事をする傍ら、周りのITとWebを活用したライフスタイルのサポートをする最高技術責任者（CTO）のブログです。 技術書の読み方は 大まかに分けて３パターンある。 ・通し読み 本を通して読む読み方。 新しい技術に取り組む時は１冊この読み方をした方がいい。 プログラミング勉強法では本を３冊読む（３冊読む為内容のURL）と書いていたが この読み方をするのは１冊目と場合によっては２冊目になる。 ・ピックアップ読み ある程度流して読み、引っかかった所だけ熟読する方法。 読んだ本が多くなってくると殆どすべての本がこの読み方になってくる。 技術書で被るポイントは結構増えてくるため、 「あれと同じだ」 と思えば、そこは読まなくても分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
