こないだの@onkさんのスライドがとても良かったんですよ。 短期間で新技術を学ぶ技術 from Takafumi ONAKA 短時間といいつつ守破離の「離」までいくのに3年かかるといってて、高速道路なんてものはないんだなということがわかりますね。 とはいえ自分自身に照らし合わせてみてもそのとおりだなと思いました。ぼくもAndroidで対外的にアウトプットできるようになるまで3年くらいかかってますし。まあ、ぼくは新技術を学ぶのはわりと苦手なほうではあるんですが。 で、スライドにはないけど新しい技術を学ぶ際には大きな壁がいくつかあるなとあると思ってます。それを 意識して 乗り越えるための指標としてもこのスライドはよさそうだなと。 ついでなのでちょっと ぼくの感じる 三大壁をまとめてみました。まあ、壁を壁と感じない人もいると思いますけどね! Lv.1 着手の壁 症状: 何の役に立つのかわからない
ヤマハや河合楽器製作所などが手がける音楽教室での演奏について、日本音楽著作権協会(JASRAC)は、著作権料を徴収する方針を固めた。徴収額は年間10億~20億円と推計。教室側は反発しており、文化庁長官による裁定やJASRACによる訴訟にもつれ込む可能性もある。 著作権法は、公衆に聞かせることを目的に楽曲を演奏したり歌ったりする「演奏権」を、作曲家や作詞家が専有すると定める。この規定を根拠に、JASRACは、コンサートや演奏会のほか、カラオケでの歌唱に対しても著作権料を徴収してきた。 音楽教室では、1人または数人の生徒と教師が練習や指導のために楽曲を演奏する。JASRACは、生徒も不特定の「公衆」にあたるとして、この演奏にも演奏権が及ぶと判断。作曲家の死後50年が過ぎて著作権が切れたクラシック曲も使われる一方、歌謡曲や映画音楽などJASRACが管理する楽曲を使っている講座も多いとみて、著作権
配色とは、他のデザイン要素と同じように、適度に使用することが大切です。最大で3つの色数に抑えることで、より良い結果を得ることができる傾向があります。デザインプロジェクトで色を適用することは、バランスを取ることと深く関係しています。使用する色数が増えれば増えるほど、バランスを取るのがより複雑になります。 色はデザインに心地よい品質を加えるのではなく、補強します。 Pierre Bonnard カラーパレットで決めた以外の色が必要がときは、色彩と色合いをうまく利用することで、異なるデザイントーンを実現できるでしょう。今回は、ウェブサイトの配色を決めるときに覚えておきたい7つのポイントを詳しくご紹介します。 60−30−10ルール このインテリアデザインルールは、いつの時代にも活用できるデザインテクニックで、配色を手軽にまとめるのに役立ちます。60%+ 30%+ 10%の比率は、バランスの良い色
Googleが運営するFirebaseを使えば、面倒なサーバーの処理は任せて、クライアント側の開発に集中できます。サンプルアプリを例に、基本的な使い方を体験してみましょう。 Firebaseは、アプリを素早く開発しデプロイできるようにするための「Backend as a Service(BaaS)」プラットホームです。Firebaseは多くの機能を提供しています。リアルタイムデータベース、ユーザー認証(Eメールとパスワード、Facebook、Twitter、GitHub、Googleアカウントを使用できる)、クラウドメッセージング、ストレージ、ホスティング、リモートコンフィギュレーション、Test Lab、クラッシュレポート、通知、アプリのインデックス付け、ダイナミックリンク、招待、AdWordsとAdMobなどが含まれています。 この記事ではシンプルなToDoアプリを作成しながら、Fir
「Front-End Developer Handbook 2017」がGitBookで無償公開。フロントエンドデベロッパーに求められるさまざまなスキル、要素技術、ツールなどを幅広く紹介する一冊 WebサイトやWebアプリケーションにおいて、ユーザーが操作する部分の開発を担う「フロントエンドデベロッパー」が扱う技術は急速に広がっています。 もちろんその基盤はHTML/CSS/JavaScriptにありますが、より高度で快適なユーザー体験を実現するにはその基盤となるHTTPやDNSといった下位レイヤの技術やSEOやUIデザイン、フォントといった細分化された専門性、そしてもちろんJavaScriptプログラミングやjQuery、React、Angularといったフレームワーク、JSONやAPIやパッケージマネージャ、ビルドツール、エディタやデバッガなどの周辺ツールとそのトレンドなど、とても一人
果たしてGitLab.comで何が起きたのでしょうか? これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時(世界協定時。日本時間2月1日午前8時)、YP氏(Yorick Peterse氏と思われる)はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く