提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
クロスプラットフォーム開発の辛み - Qiita
クロスプラットフォーム開発経験 クロスプラットフォームというと主語がでかいですが、Titanium Mobileを指します。 Titanium Mobile開発経験約二年です。 出したアプリiOS6本/Android3本。 (Androidはストアから削除した/された) iOS: Kensuke Hoshikawa のソフトウェアを iTunes でダウンロード 最近はTitanium辞めてSwift書いてます。 Titanium Mobileの辛み クロスプラットフォームは幻想 iOSで開発完了→Android対応が容易ではない 自分の場合、iOSにかけた時間の1.5倍くらいは必要だった Android対応あきらめたアプリもある ソースコードの中でiOSとAndroidの切り分けが頻発 バグがあった場合、Titaniumのバグかネイティブのバグかわからない パフォーマンスがでない、カクカ
React Native ファーストインプレッション - Qiita
React Native 概要 React.js とだいたい同じ作法で、JavaScript で書いたコードが iOS ネイティブアプリとして一応動く。そのフレームワークと開発環境を提供する。 React.js と同じ React を謳っているとおり、JSX で UI コンポーネントを定義するとか、Props や State で View のデータフローを整えるとか、setState() によるデータバインディングとか、諸々が一緒。従って React.js でアプリケーションを作ったことがあれば、学習コストをほとんどかけずにアプリが作れる･･･かも 例えば以下のように、入力値をそのまま画面にエコーするアプリケーション。 これはこんな感じのコードになる。 var React = require('react-native'); var { AppRegistry, StyleSheet, T
step by stepで始めるKarma - Qiita
Karmaを使うことでフロントエンドの単体テストを楽しくかつ機能的に行うことができます。 ステップを通して少しづつ理解できるように執筆しました。 また、最後に重要だろうと思われる補足内容を記載しました。 Karmaの導入に一役買えれば幸いです。 テスト全体の流れについては以前書いた記事フロントエンドにテストを導入を参照してください。 Karmaとは ブラウザ上で 単体テストを実行するためのテストランナーです。 テストを実行するだけでなくファイルの変更監視や結果のレポートを出力してくれたりと単体テストに必要な機能が一通りそろっています。 特定のフレームワームに依存しておらず汎用的に使えるツールで、プラグインを使った機能の拡張が強力です。 前提 Nodejs,npm,chromeが導入済みであること 流れ Karmaは4つの大きな機能（プラグイン）が存在します。 Step 3 〜 Step 6
今、Fintechスタートアップを始める時にどんな言語を選ぶべきか？ - Qiita
現在、Fintech系のスタートアップを始めるにあたって、以下の言語で選定を迷っている。 フロントエンド（これは決定済み） Reactjs ReactNative redux バックエンド Node.js Golang Elixir (Phoenix) Ruby (RoR) Python PHP どんなプロジェクトか？ 会計に関する業務オートメーションサービス 企業向けとそこの従業員さん向けのサイトとアプリが必要。 細かな設定や20種類のレポートページ、情報ダウンロード、データ登録、データ編集がある。 アクセスは、契約した企業に限定され、同時アクセスは、1000ぐらいを想定しておけば問題ない。 会計に関するビジネスロジックには絶対にバグを出せない。 長く続けていくプロジェクトなので、今後、優位性のある言語を選びたい Node.js 採用すべき理由 僕が今最も書ける言語 npmが本当にすごい
[JavaScript] Mapのpolyfillをコードリーディングして分かった利用時の注意点 - Qiita
TL;DR babel-polyfillでMapのpolyfillを使う場合、2点注意することがある。 ES5環境では、Object.freezeなど、オブジェクトにプロパティを生やせなくする操作をしたオブジェクトをキーに持つマップを作ると、getなどの操作がO(1)でなくO(n)になってしまう。 ES3環境では、オブジェクトをキーに持つマップを作成すると、キーに使用したオブジェクトに勝手に列挙可能なプロパティを生やされるので、for-inしているコードがバグる可能性がある。 前提知識 Mapといえば、ES2015の新機能である。 ES5以前は辞書型に相当するものを使いたい場合、オブジェクトを代用品として騙し騙し使うことが多かったが、ES2015でMapが提供されたことで、これからはオブジェクトにあった制約を気にせずに辞書型を使うことができるようになった。 オブジェクトを辞書型の代用品とし
![[JavaScript] Mapのpolyfillをコードリーディングして分かった利用時の注意点 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4a9719d4fe129529a6af062bf42a2280c287c2a3/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCSmF2YVNjcmlwdCU1RCUyME1hcCVFMyU4MSVBRXBvbHlmaWxsJUUzJTgyJTkyJUUzJTgyJUIzJUUzJTgzJUJDJUUzJTgzJTg5JUUzJTgzJUFBJUUzJTgzJUJDJUUzJTgzJTg3JUUzJTgyJUEzJUUzJTgzJUIzJUUzJTgyJUIwJUUzJTgxJTk3JUUzJTgxJUE2JUU1JTg4JTg2JUUzJTgxJThCJUUzJTgxJUEzJUUzJTgxJTlGJUU1JTg4JUE5JUU3JTk0JUE4JUU2JTk5JTgyJUUzJTgxJUFFJUU2JUIzJUE4JUU2JTg0JThGJUU3JTgyJUI5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz02OTkzNTM4NTNkZjAwNWVmMzI0MDk1ZWQ2YzBlY2NmOA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBhbnFvb3FpZSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MWI2YjM3NTQ2NWU2MzcxNDBlNWEzZjNkY2NjMTI2MTQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dba2cfbfbea75d0ef8d4690ae48cbd1f0)
オブジェクト指向と20年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav
[Facebook]アイコン画像URLをサイズ別に取得する - Qiita
※リンク内のsatoukentaは僕のIDなので適宜読み替えてね https://graph.facebook.com/satoukenta/picture?type=large https://graph.facebook.com/satoukenta/picture?type=normal https://graph.facebook.com/satoukenta/picture?type=small ↑上にいくほど大きい（GETパラメータのtypeを見てね） この方法だと、縦長、横長の画像をプロフィール画像に設定している人のアイコンを正方形で取ってこれないので、 とする。（type=square!） けど、サイズ小さいよね・・・。 そこで、 とやってやると320×320でトリミングされた大きい画像が取得できる！ アプリやWebサービスでFacebookアイコンを使う場合はこちらでアイ
![[Facebook]アイコン画像URLをサイズ別に取得する - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d9302c405b26b1bea275be75f469f27fcd7659e/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCRmFjZWJvb2slNUQlRTMlODIlQTIlRTMlODIlQTQlRTMlODIlQjMlRTMlODMlQjMlRTclOTQlQkIlRTUlODMlOEZVUkwlRTMlODIlOTIlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTUlODglQTUlRTMlODElQUIlRTUlOEYlOTYlRTUlQkUlOTclRTMlODElOTklRTMlODIlOEImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWU3MTlkOTVjNzVlOWM3ZmM5NDM2NTdmZTRhMTJjYTcx%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc2F0b2tlbjA0MTcmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWUzMTQwY2NhNmRkYmU5MjQxMTYyNmQ2NmFkNWFlNWMw%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Db390e4636c5c1d9e99dbf887b1f0eee4)
フロントエンドにテストを導入 - Qiita
2016-8-8 ※webpack単体の記事を書きました。よろしければこちらもどうぞ step by stepで始めるwebpack 2016-5-16 ※karma単体の記事を書きました。よろしければこちらもどうぞ step by stepで始めるKarma 本記事は画面のJavaScriptのテストとかまったくやったことない方 Mocha？webpack？karma？それぞれの解説記事はよく見るけど全体像がよくわからんという方向けです。（数日前の自分です） 全体を通して導入の流れを解説した記事があると全体像が理解しやすいのではと思い書いてみました。 前提 Nodejs,npm,chromeが導入済みであること 流れ Step 表題 目的
NG-CONF 2016の雑な覚え書き - Qiita
Angular界隈における年に1度のお祭りイベント、ng-conf。今年(2016年)は5/4~5/6にSalt Lake Cityで開催されました。 現地には行っていませんが、ng-conf extend Tokyoというイベントに参加し、1日目と3日目のSessionをpublic viewing的に眺めてきたので、その覚え書きです。 1日目(5/4) Keynote 動画 Angular2の性能の話や周辺エコシステムの話など。聴きながら触ってみたい！と思ったのは下記： Augury AngularJS 1.xでいうところのBatarangle的なツール. 後述. Angular CLI Angular2の雛形プロジェクトや、componentのscaffoldingをしてくれたりするツール。後述. NativeScript 2.0 Mobile向けのプラットフォームであるNative
Angular2のServer Side Renderingに触れてみる - Qiita
はじめに 今回のエントリでは、 Angular2 とServer Side Rendering(以下SSR)について書きたいと思います。 Angular2でSSRを実現するためのモジュール群は angular-universal で開発されています1。 コーディングレベルでのモジュール利用方法についても記載しますが、APIや利用可能なオプション等の詳細については日々刻々変化が予想されます。 今日時点では、Angular2の開発チームが目指しているゴールと、それを支えているアーキテクチャについて理解しておいた方が今後の変化に柔軟に対応できると考えています。今回のエントリでも、この点を踏まえて書いていくように努めます。 前半でAngular UniversalのDesign Docを交えながらSSRの仕組みに関する話を、後半でExpressと連携させてAngular Universalを動作さ
Falcor入門 1日目 Falcorとは何者か - Qiita
はじめに 最近、ある程度の時間を割いてFalcorを触っています。 まだ日本語での情報は豊富とは言えない状況ですし、自分の理解を整理する意味も含め、何回かに分けてFalcorについて書いていきます。 1日目の今日は「Falcorとはどのような目的のために生まれ、どのような仕組みに依存しているのか」を説明します。 概念的な話ばかりでコードは殆ど出てきません。実装寄りの話は次回以降に書きますが、行ったり来たりしながら読むのも有りじゃないかなと思います。 ちなみに次回以降の目次はこちら： Falcor入門 2日目 FalcorのJSON Graphに触れてみる Falcor入門 3日目 Falcor Routerでサーバサイドを実装してみる Falcor入門 4日目 FalcorとReactを組み合わせる 昨今、Webアプリケーションの大半は、ReactやAngularなどのMVCフレームワーク
転職ドラフトのデータから、どんな技術を持っている人が多いのか、集計してみた - Qiita
サイトには、具体的な年収額は公開されていない。 （会員登録して職務経歴書まで入力すると具体的な提示額が見えます） そのかわりに、年収を6段階に分けて、名称を付けて表現している。 それが「ゴッド、ウィザード、スター、プチリッチ、ノーマル、ノービス」だ。 システムエンジニアSEの年収-年収ラボによると、平均が542万だそうだ。 その辺りから類推すると良いかもしれない。 感想としては、意外とノーマルより上が多い、という印象だ。 しかしここには落とし穴があって、 原則、提示年収の80%〜の金額が内定時の予測年収です。 という但し書きがあることは、共有しておきたい。 極論すると、ワンランクずつ下がる可能性がある。 プチリッチがノーマルにシフトすると考えれば、一番多いことにも少し納得する。 どの年齢層が居るのか？ 年代 人数
jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
素振り環境を晒す2016年春 - Qiita
追記161231: 続編を書きました。『素振り環境を晒す2016年末』 @armorik83です。みなさん素振りしてますか。 素振りとは この辺。 JavaScriptのトレンドを素振りして確認する方法 JavaScriptの素振りする技術 私はだいたい設計の下書きやペアプロなどでBabel replやTypeScript Playground、あとはPlunkerとJSFiddleあたりをよく使ってます。 いくつかのライブラリを組み合わせたいとき、昔はCDNから取ってこられたので簡単だったけど、最近はnpm iした方がむしろ準備が早いケースも増えてきて、組み合わせての検証や練習をする際に、素振り環境は持っておくに越したことはないです。 素振りpackage.json { "name": "suburi", "version": "0.0.0", "description": "", "m
GoConの前哨戦として各種API仕様記述フォーマットについて概要を述べておく - Qiita
この記事はGoCon 2016 springで話す内容を圧縮するためのものです。 WebサービスのAPI仕様を記述したりするためのそれなりに有名な仕様について、筆者(@vvakame)の私見を述べていく。 なお、Google Trendの結果を見ると…。 仕様を調べてSwaggerを選択する事にしたのは1年弱程度前のはずなので、もし "今はそれもうできるよ！" とかあったらコメントなどで教えてください。 RAML RESTful API Modeling Language なので、手書きを前提にしている。 YAMLで頑張って仕様を書く。 Spec APIs Explorerっぽいものもあるっぽい。 総評 比較的広く使われているようでパワを感じる。 まず仕様が先というスタイルなのがめんどくさそう。 YAMLなのがちょっとイヤ。 RAMLからGoとJavaScript(TypeScript)向
React.js 実戦投入への道 - Qiita
最近話題のReact.jsですが、実戦投入に当たっては結構重たい選択を迫られることになります。 ざっくり言えば、テンプレートエンジンを捨ててReactしますか?それともReactあきらめますか?という選択です。 本記事ではReactの基本思想とこうした選択肢が生まれてしまう背景を述べるとともに、後半では「どちらもあきらめない」という(若干シミュレーションRPGあるある感のある)第三の方策について案を提示します。 Reactの基本 最初に、Reactの基本的な仕組みについてまとめておきます。 Reactは公式ドキュメントが非常に充実しているので、始める際はぜひQuick Startのドキュメントに目を通すことをお勧めします。 Getting Started Tutorial Thinking in React 後述しますが、Reactを使ってアプリケーションを作る際の設計方法についての記載が
「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い - Qiita
はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指
Go 言語に関するブックマーク - Qiita
本業が忙しくて Go 言語をかまってあげる暇がないのだが，ブックマークばっかり溜まっていくので，定期的に吐き出しておく。なお， Qiita でのメンテナンスは終了することにした。以降は以下のページでメンテナンスしている。 Go 言語に関するブックマーク - プログラミング言語 Go | text.Baldanders.info 公式サイト The Go Programming Language : 2017年1月26日時点での最新は 1.7.6 git repositories (Google) git repositories (GitHub) : mirror golang-jp - The Go Programming Language : 本家の日本語訳サイト。（golang.jp は内容が古いので参考にしない方がいい，らしい） Go 1.5 Released. Go 1.5 is
オブジェクト指向言語としてGoをやろうとするとハマる点を整理してみる - Qiita
Earth Pony walk 歩くよ Earth Pony Sprint 歩くよ 歩くよ 歩くよ Pegasus Walk 走るよ Pegasus Sprint 歩くよ 歩くよ 歩くよ こうしてみるとこのような実行結果になることが自然だとわかると思います。 つまりどういうことかというとGoの埋め込みは継承ではなく委譲だということです。 2. 埋め込みとは何なのか？ 委譲は従来の実装継承と比較して以下のような冗長なコードが増えてしまいます。 委譲元のクラスに対して委譲先のインスタンスを渡す 委譲元のクラスでは委譲先クラスのインスタンスを受け取れるようにメンバを宣言 委譲元のクラスに委譲先の関数を実行する処理を記述。関数の数だけ必要。 Go以外の言語を書いているときは諦めて素直に上記のような冗長なコードを書いていました・・・が！ Goではこの冗長なコードを埋め込み(embedded)を使うこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
