gulpfile スタイルガイド - v0.5.0 - Qiita
このドキュメントは、gulpfileの再利用性/メンテナンス性を高めることを目的とした、非公式なスタイルガイドです。 更新情報 2014/10/05 - バージョン番号つけました。 2014/10/04 - 「タスク辞書」あらため「タスクの共有」に。以前の内容はgulpfilesとして別ドキュメントに。 はじめに gulpfileはgulp.jsのタスクを定義するファイルです。スクリプトファイルなので自由に書ける反面、プロジェクトが大きくなると、書式を統一が問題になります。そんな時、このスタイルガイドが役に立つでしょう。対象となるのは次のようなケースです。 gulp.js に慣れて来て、再利用性のあるタスクを書きたい チームで運用する必要があり、書式を統一したい スタイルガイドとして、下記を参考にしています。また、ここで述べない JavaScript / CoffeeScript の言語と
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
工数見積の際に子供の看護リスクを織り込む計算式 - Qiita
シビアに見積もった工数をdとした時の計算式： d + d(( r1 [ + r2 … + rn] ) * x1 [* x2] ) 例 例）1, 3, 5歳の子供がいて、夫婦で看護を半々にシェアできるエンジニアの当初の見積工数が30人/日、時期は1月~2月の場合 30 + 30 * (( 0.04 + 0.04 + 0.02 ) * 1.2 * 0.5 ) = 31.8 ということで計算後の見積工数は32人/日ということになります。 さいごに 半分ネタで半分本気です Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWh
microservicesに分割する際に注意するべき5つのこと - Qiita
はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくことです。ですので、プロセスを跨いだ通信が大量に発生します。その結果、サーバー台数は増大します。 つまり、インフラコストの増大と開発速度の高速化のコスト感覚をバランスして判断していく必要があります。疎結合性が高まり、アーキテクチャとしては美しく感じますが、実施に
レガシーIEのデバッグ環境について - Qiita
口上 モダンブラウザが普及した今日、いまだレガシーIEは死なず。 つまりそれはクロスブラウザ動作確認をIEでも行わなければならないことを意味する。 IEである。 レガシーIEの入手方法について モダンな開発者であれば仮想マシンは常識であるのでmodern.IE( https://www.modern.ie/ja-jp/virtualization-tools )を使用する。各ホストOS向けにイメージが配布されているのでそれをダウンロードすればよい。 ただし中身はIEしか入っていないWindows環境なので後述する方法でデバッグ環境を構築する必要がある。さもなければ死ぬ。 デバッグ環境の構築について Microsoft Script Editorかそれが同梱されているMicrosoft Officeを所持しているならばそれをインストールして使用する。 所持していなければVisual Stud
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
Goにatexitやグローバルなデストラクタがない理由 - Qiita
CやC++ではatexit関数で関数を登録しておくと、プログラムの終了時にその関数を自動的に走らせることができる。そういう機能はRubyやPythonにもある。 Goにはそういう機能はない。実装を忘れているのではなくて、意図的にそういう機能を持たせていないのだ。これについてIan Lance Taylorさんが大変説得力のある説明をしていた。 まず第一に、どんなプログラムでも任意の箇所でクラッシュしうるし、まったくバグのないプログラムでもいきなりkillで殺されたりマシンが電源断で落ちるということがある。従ってどんなプログラムも、突然終了させられたあとに、もう一度きちんと動くことができなければならない。つまりatexitはきれいに終了するための機能ということで、atexitが呼び出されないとうまく動かないプログラムというのはそもそも間違っているということになる。 大きなC++プログラムでは
Goでxxxのポインタを取っているプログラムはだいたい全部間違っている - Qiita
Goで、文字列、インターフェイス、チャネル、マップ、スライスのポインタを取っているプログラムは、書いた本人がきちんと自分がなにをしているのか理解しているのでなければ、ほぼ確実に間違っているといっていい。 Goではある種の型の値はそもそもポインタのようなものである。上記の型はどれも任意の大きさになり得るが、大きくなりうる実体のデータはヒープに確保されていて、値そのものが持っているのはそのヒープ上への値へのただのポインタ＋多少の付随的なデータにすぎない。こういった値を値渡しではなくポインタ渡しする必要はない。ポインタのデリファレンスのほうがポインタのコピーより高くつくし、余計な混乱を引き起こすだけだからだ。もしこういう値をポインタ渡ししているとしたら、そのコードはなにか深い意味があるのではなく、それを書いた人が大きな値がコピーされると勘違いしていて書いた可能性のほうがずっと高い。 文字列は2ワ
RailsでAPIをつくるときのエラー処理 - Qiita
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
「これだけ」モデリング - Qiita
これだけモデリングとは 「これだけモデリング」とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。 そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 エンタープライズアジャイル時代のリーンモデリング（slideshare） これだけモデリングとは、 誰が？ ー 情報システム部門の
Railsをバージョンアップし続けるために必要なこと - Qiita
本当は、RubyWorld Conf辺りでこういう内容も交えてなんか話せればいいなあと思ってたんだけど、CFPに落ちたのでQiitaにポエムを書いてみました。 Railsはそれなりに学習コストはかかりますが、慣れてくるとデフォルトで便利なものが揃ってるしサードパーティライブラリも豊富で、未だに最も便利なWebアプリケーションフレームワークの一つだと思います。 なので、最近のスタートアップ界隈ではRailsで開発をスタートする、という話をよく耳にします。(個人の感想です) しかし、Railsは本体に新しい要素をガンガン取り入れてくるので、バージョンアップのサイクルはかなり早く、それに追従していくのはそれなりに大変です。 Railsで開発をする場合には、一旦レールに乗ったらプロダクトが死ぬまで走り続ける覚悟が必要です。(時速60km以下になったら爆発する) それを最初に理解しておかないと、あっ
TypeScriptとECMAScript 6 - Qiita
来たる8/23(土)にLL Diverというイベントでmozaic.fm出張版があって、そこで適当にTypeScriptの何かを話す予定なので、ECMAScript 6の予習をしていきます。 司会のJxck先生は知識量豊富なので予習していかないとボコられて恥を晒して死んじゃうからね！ あんどうやすしさんは優しいと思うんだけど！！ 参考資料 わかめのECMAScript6のはてブ ECMAScript 6のドラフト(ログ) ECMAScript 6で提案されたもの ECMAScript 6 compatibility table es6-shim ECMAScript6をまるっと学ぶ。重要用語とか、仕様策定の進め方とか、新機能とか。 traceur-compiler入門 ECMAScript6をまるっと学ぶ。はすごい参考になったのでぜひ読むべきそうすべき。 この辺りをガシガシ読んでこの記事を
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
HTMLでWeb APIをつくる - Qiita
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか？ ビューに書いた方が自然ではないでしょうか？ これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
RSpec の入門とその一歩先へ、第3イテレーション ～RSpec 3バージョン～ - Qiita
はじめに 本記事は和田卓人さん(@t_wada)が書かれた有名なRSpec入門記事、「RSpec の入門とその一歩先へ、第3イテレーション」をRSpec 3バージョンとして書き直したものです。 詳しくは第1イテレーションに書いた説明を参照してください。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション 第2イテレーション 第3イテレーション(本記事) ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/3rd 本記事のライセンスについて 本記事は クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 備考 本文やサンプルコードは極力オリジナルバージョンを踏襲します。 記述が古くなっている箇所は新しい記述方法に書き直します。 新しい記述方法や和田さんの
RSpec の入門とその一歩先へ、第2イテレーション ～RSpec 3バージョン～ - Qiita
はじめに 本記事は和田卓人さん(@t_wada)が書かれた有名なRSpec入門記事、「RSpec の入門とその一歩先へ、第2イテレーション」をRSpec 3バージョンとして書き直したものです。 詳しくは第1イテレーションに書いた説明を参照してください。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション 第2イテレーション(本記事) 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter2 本記事のライセンスについて 本記事は クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 備考 本文やサンプルコードは極力オリジナルバージョンを踏襲します。 記述が古くなっている箇所は新しい記述方法に書き直します。 新しい記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goの変数名が短い理由（あるいはGoがほかの言語と違う理由） - Qiita
@ruiuのマイページ - Qiita
大手Webサービスがクライアント側で発生したJavaScriptのエラーをどう収集しているのか まとめ - Qiita
