プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
どうして女子は「美容院行ってきたよ」っていわないの？
それで髪型の事に触れないでいると「わたし美容院行ってきたんですけど」とカチキレ。 嫁はその後も「わたしを見てない」とか「どうせ興味が無い」とか「男はいつもそうだ」とかまじでウゼェ。 そういや数日前に「○日に美容院行ってくるね」とか言ってたけどこっちはいつも仕事のことで頭が一杯なんだから覚えてるわけがない。 しかもどうみても気づかれるほど変わってないのに「毛先のカールが」とか「前髪が」とか言い出して、気づかないほうが悪いというスタンス。 それって完全にマウント取りたいだけなんじゃないの？ 大体にして、どうして素直に「美容院行ってきたけどどう？」って聞けないものか。 ほぼ女性全員が「気づかない男性が悪い」っていう構図を作りたがるけど、歩み寄ろうとしてないのそちらですから。 男は外に注意を払う生き物で、女子は環境を整える生き物なんだからそれでいいじゃない。 営業テクニックの話とか聞こうともしない
マイクロサービスとドメイン駆動設計の設計思想のTwiiter拾い
鈴木雄介/Yusuke SUZUKI @yusuke_arclamp マネジメントで大事なのは、計画や実行だけでなく、状況を見極め（計測）、対応する行動をおこす（調整）ことですよ。なので、マネジメントの土台にもアーキテクトの「ドメイン（問題領域）を見極める能力」は極めて重要です。 2015-04-30 15:17:23 鈴木雄介/Yusuke SUZUKI @yusuke_arclamp ドメインモデルはビジネス上のデータ活用についての仮説を表している、、というのは認識していただきたい。平面的にデータを捉えるのではなく、立体的にデータを捉えるのがモデルですよっと。 2015-04-30 17:18:42 鈴木雄介/Yusuke SUZUKI @yusuke_arclamp アジャイルにPMが不要だというのは、計画、実行、計測という機能はプロセスに溶け込ませてスクラムマスターが支援する。そし
無限リストによるエラトステネスのふるい - Qiita
Elixir では Stream モジュールを使って、遅延評価と無限リストを扱うことができるがそれによりエラトステネスのふるいを、Haskell と同じように無限リストを使った記述ができるか･･･というのが今回の試み。結果としては、カッとなれば、できる。 以下、Stream の解説も交えてお届けする。 Enumerable プロトコルと Enum および Stream Elixir の Enum モジュールには map/2 や filter/2 や zip/2 など、コレクション操作に必要な関数が多数実装されている。以下はそのドキュメントの例である。Functions のところに Enum の関数が列挙されているのが分かる。 ちなみにこのドキュメント閲覧は Dash の画面。自分は主に iOS 開発のドキュメント閲覧によく使っているが、見ての通り Elixir のドキュメント参照にも便利。
「外部キー Night」に参加してきた - ichirin2501's diary
発表者として参加させていただきました。 発表資料はこちらです（自分でも忘れそうなのでブログにリンク貼っておく） 外部キー制約に伴うロックの小話 from ichirin2501 外部キー制約に伴うロックの小話 追記: 2015/08/22 ブログでも補足したほうが良いかな、と思ったので今更追記することにしました。 どういう資料？ 外部キー制約で発生するロックのお話です。前提として、MySQL(5.5.28)のInnoDBストレージエンジン、トランザクション分離レベルはREPEATABLE-READ, READ-COMMITEDです。上記は検証環境ですが、MySQL5.1 ~ 5.7でも変化していない挙動のはずです。また、InnoDBのロックはインデックスレコードロックなので、インデックスに対する理解が必要不可欠です。発表時間も20分程度ということもあって、その辺りをある程度理解されてる方が
10回目の最後のYAPCに2回目の参加をしてきた - sakaikの日々雑感～(T)編
2015年8月21-22日に東京ビッグサイトで開催された YAPC::Asia TOKYO 2015 に参加してきました。Perlのお祭りです。 毎年開催は知っていたものの、日程が合わなかったり、迷っているうちにチケットが売り切れてしまったりして、過去に参加したことがあるのは、たったの１回。それでも「すごいことを、いとも当たり前のように楽んでいる」という雰囲気がとても印象に残っていました。 そんなわけで、10年を迎えた2015年。今年で一旦 YAPC::Asia を最終回とするとのアナウンスがあり、万難を排してスケジュールをあけ、この日を楽しみにしていました。 0日目（前夜祭） 木曜日の夜。ビールとスナックが用意されて、2トラックのセミナー形式。前夜祭なのに2トラック。なんといっても、鶉(uzulla)さんの講演芸にすっかりやられました。会場の空気のつかみ取り方が素敵。見習いたいけどたぶん
発信したい気持ち、Podcast、エンジニアではないぼく。YAPC::Asia Tokyo 2015。
ぼくは残念ながらエンジニアではない。 大学の文系学部を卒業し最初に入った会社はゲーム会社だったけれども仕事は事務。 ゲームを作りたいと思っていたんだけれどもどうやったら作れるのかよくわからなかった。 今思うとリサーチ力不足も甚だしいのだがプログラミングなるものをあの時点で知っていたとして僕はゲームを作れたのだろうか。 それはどうにもよくわからない。 ただ今、言える事はぼくはWebサービスを作ってみたいのに作る技術がないということである。 ジーズアカデミーと言うゼロからエンジニアを目指そうと言う学校に通っていて、HTML/CSS/JavaScript/PHP/MySQLの最低限は使えるようになったんだけど。 卒業制作としてWebサービスを作りロンチするという当座の目的地を見上げると、悩みが尽きない。 前置きが長くなった。 そんなわけでのアカデミーの課題と言うやるべきことをやっていない状態であ
Erlang Solutions - Scalable Distributed Technology
We build transformative solutions for the world’s most ambitious companies. By providing user-focused consultancy, high tech capabilities and connection to diverse communities. We’re the world-leading experts at building massively scalable distributed systems. We have over 20 years of experience building critical digital infrastructure that scales to billions of users without error. We create a re
Shibuya.ex #1 Elixirを本番環境で使ってみたという事例紹介
20170622 Heroku Meetup #17 スタートアップのインフラ選び 高丸翔英 How to choose infrastracture...Shoei Takamaru
地獄のElixir(目黒スタートアップ勉強会)
DMM TVでの自動テスト構築と QA部でのSaaS型の テスト自動化プラットフォームの活用_slideshare用.pptxHiroyuki Hanaue
YAPC::Asia 2015にいってきました - だいたいそれでいいんじゃないの
2015-08-22 YAPC::Asia 2015にいってきました タイトル通り。会場のビッグサイトの下のカフェで書いてる。 10回目で最後のYAPC。自分は最後の３回しか参加してないけど、Perlだけでなく様々な言語・様々なレイヤーの話がわいわいされててエンジニアのお祭りって感じですごくたのしかった。 トークいくつか聞いたけど、おそらくスピーカーのひとのが資料あげてるのでそちらを参照するとおもしろいよ！ HTTP2の話はすごく面白かったので一度、かるく導入してみたいと思った！ すごい大規模だしとてもおもしろいカンファレンスなので終わってしまうのはかなしいけども、これも区切りなのかなと無理やり納得してる。また違うかたちでこんな雰囲気のカンファレンスが開催されると嬉しいです。 カンファレンスとか勉強会に言った後はすごくモチベがあがるのでそのままコーディングするのがいいなーと思っていたの
SHIROBAKOみゃーもりの優秀さ
Stargazer Meetup #1 http://connpass.com/event/18896/
YAPC Asia 2015「Google Cloud Platformの謎テクノロジーを掘り下げる」のまとめ - Qiita
YAPC::Asia Tokyo 2015、ロゴのとおりに熱いイベントでした...今年で最後なのはほんとに惜しいです。最初にして最後の参加となった私は、「Google Cloud Platformの謎テクノロジーを掘り下げる」というタイトルでトークをさせていただきました。 スライドはここに上げてありますが、これだけ見ても意味不明と思われるので、話した内容の要約をまとめブログ代わりに書こうかな、と思ったらかなり長文となってしまいました。基本ポジショントークですが、しかしGoogleに入る前からGoogleクラウドに対して持ち続けている気持ちでもあるし、ここはイケてないなーと思った部分は素直にそう書くようにしました。 しかし謎は謎のまま... Twitter上の反応まとめを見ますと、「謎が謎のまま終わった」とのご指摘も多く、これはほんとに私の不徳の致すところです、申し訳ありません……。スライド
The Art of Computer Programming Volume 1 Fundamental Algorithms Third Edition 日本語版
The Art of Computer Programming Volume 1 Fundamental Algorithms Third Edition 日本語版 Donald E. Knuth(著), 有澤誠, 和田英一(監訳), 青木孝, 筧一彦, 鈴木健一, 長尾高弘(訳) アスキードワンゴ 4,224円 (3,840円+税) アルゴリズムのバイブル――Knuth先生の名著『The Art of Computer Programming』シリーズの第1巻! Volume 1「基本アルゴリズム」では、コンピュータプログラムの基礎概念と情報構造を学習します。 関連サイト本書の関連ページが用意されています。 The Art of Computer Programming Volume 1... - アスキードワンゴ内容紹介◆アルゴリズムのバイブル――Knuth先生の名著『The Art
The Art of Computer Programming Volume 2 Seminumerical Algorithms Third Edition 日本語版
The Art of Computer Programming Volume 2 Seminumerical Algorithms Third Edition 日本語版 Donald E. Knuth(著), 有澤誠, 和田英一(監訳), 斎藤博昭, 長尾高弘, 松井祥悟, 松井孝雄, 山内斉(訳) アスキードワンゴ 4,224円 (3,840円+税) アスキードワンゴ始動 第2弾!! Knuth先生の名著『The Art of Computer Programming』で準数値演算を極める! 関連サイト本書の関連ページが用意されています。 The Art of Computer Programming Volume 2... - アスキードワンゴ内容紹介◆Knuth先生の名著『The Art of Computer Programming』で準数値演算を極める!「問題は、コンピュータに数
今死んだらどうする？一人暮らしの20代だからこそ書きたいエンディングノートのススメ - クートンブログ
一人暮らしをしていると、ふと「今、死んだら、部屋にあるガラクタやお金ってどうなるんだろう。友達宛の葬式の連絡とか親はやってくれるだろうか」と思うことが度々あります。 そんな漠然とした不安を解消してくれるのが「エンディングノート」です。 エンディングノートは、自分が死んだり、意思疎通ができなくなったりした時に、相手に伝えることをまとめたノートを言います。 自分の半生を振り返る為に30～50代の人や、病気や老いなどの理由で「終活」の目的でお年を召した方が書くイメージがありますが、正直、地元を離れて暮らし、家族とは盆と正月の年に2～3回しか会わず、恋人や友人とも月何回かしか会わず、いつ死んだか分かりにくい、私のような20代の一人暮らしの人も書くべきだと思います。 エンディングノートには、遺言のような法的効力はありませんが、自分の忘れてはいけない備忘録やメッセージ、希望の通達に役立ちます。 エンデ
身内が死んで実感した、いつ急死しても良いように最低限準備しておきたい6つのこと - クートンブログ
「生前整理」や「終活」と聞くと、20~30代の若い世代にとっては「自分の親や祖父母が行なうこと」というイメージがありますが、人はいつ死ぬか本当に分からないものです。 私事になりますが「大きな病気や怪我一つせず、全然死ぬ気配も無かった身内が突然亡くなる」という経験をしたことをきっかけに「自分が突然死んでも大丈夫なように、残された人に多くの面倒をかけない為の準備はしておくべきだな」と思うようになりました。 特に地元や親元を離れた一人暮らし、独身、単身赴任で生活している人にとって「万が一に備える」ことは、家族で暮らしている人よりも真剣に取り組むべきことのように感じます。 そこで今回は「いつ急死しても良いように、最低限準備しておきたいこと」をまとめてみました。 自分の今後を考えるきっかけになれば幸いです。 遺影用・葬式映像用の写真をプリントアウトしておく 最近は私を含めて「撮った写真はデジカメやス
プロダクトマネジメント(あるいはオーナシップ)に関心のあるひとが集まるSlack Teamを作成した - Kentaro Kuribayashi's blog
プロダクトマネジメント、あるいはプロダクトオーナシップに関心のあるひとが集まるSlack Teamを作成しました。以下のページから参加できます。 Join Product Managers Japan on Slack! 追記: Product Managers JapanのWebサイトもできました。そちらも御覧ください → Product Managers Japan (PMJP) 昨今、プロダクトマネジメントに関心が集まっています。最近の盛り上がりは、Rebuildで語られたりなどによるものだと思いますが、しばらく前に出た『世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法』『プロダクトマネジャーの教科書』などにより、アメリカのWeb業界におけるその職能が紹介されてもおり、また、『スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB
gccとclangのラムダ式に関する最適化具合の違い - Qiita
gccとclangでclangの方が顕著に最適化してくれてる例を見つけたのでメモがてら。 環境は GCC 4.9.2 20150212 (Red Hat 4.9.2-6) clang 3.5.0 (tags/RELEASE_350/final) です。 テストコード class S { private: int a; int b; int c; public: S(const int aa, const int bb, const int cc) : a(aa), b(bb), c(cc) {} int A() const { return a; } int B() const { return b; } int C() const { return c; } }; template<typename F, typename G> int Func(const S& s, const G&
Scala with DDD
Indroduction Xtend, Extending Java, Statically typed, Closure, Extension method
pelletkachels | blog over bedrijven en feitjes en de pelletkachel
Welkom bij Pelletkachels.nl, jouw ultieme bron voor alles wat met pelletkachels te maken heeft! Maar we zijn meer dan alleen een platform voor het bespreken van warmtebronnen. Bij Pelletkachels.nl geloven we dat het delen van kennis en ervaringen over bedrijven en gebeurtenissen ook essentieel is voor het creëren van een betrokken en geïnformeerde gemeenschap. In dit blog duiken we dieper in de we
『YAPC::Asia Tokyoの10年間』
馮富久のブログ - Tomihisa Fuon's Blog 馮富久が書くブログです．よろしくお願いします． This blog is written by Tomihisa Fuon. 2015年8月20～22日の3日間，東京ビッグサイトにてYAPC::Asia Tokyo 2015が開催されました。 YAPC::Asia Tokyo 2015 http://yapcasia.org/2015/ 詳細は公式サイトやgihyo.jpのレポート等々にお任せするとして，今回で10回目，そして，まずはYAPC::Asia Tokyoの形として最後ということもあって，個人ブログで初めて書いてみます。 ちなみにこれまではmixi日記でずっとログだけ残していたので，今回はそこから写真を使いつつ，写真で振り返るスタイルで。 ■2015 会場はビッグサイト。 メインの国際会議場は1,000名の収容人数。
ウォンテッドリー株式会社 が引っ越したらしいので行ってきた！ - 941::blog
セイッ！ くしいです！ さて、行ってきたシリーズ108記事目となる今回は、以前もお邪魔したことのあるウォンテッドリー株式会社さんどす。 「はたらく」を面白くするサービス Wantedlyなどを手がけていて、お引越しされたとのことで行ってみたけどもいやはや凄い。新しいカルチャーが生み出されるNYのコワーキングエリアをイメージしたという新オフィス、CEOのこだわりが随所に詰め込まれていて超カッコよかったッス。 過去にお邪魔したのはこちら。 2013年11月29日 ウォンテッドリー株式会社 に行ってきた！ 受付、ドジャーン！かっこいい ==== 派手やなー！ ※公開から3ヶ月以上経過した特定の記事は有料となっている場合があります この続きはcodocで購入
良い記事を書くためのガイドライン | Qiita ヘルプ
良い記事を書くためのガイドラインこのガイドラインについて Qiitaは、プログラミングに関する知識を記録・共有するためのサービスです。Qiita上の記事は、投稿者以外の人にとっても価値のある記事であることが望まれます。 あなたの知識が他の誰かの役に立つようにするために、このガイドラインを参考にしてください。 役に立つ記事を書くために Qiitaに投稿した記事はフィードに表示され、他のユーザーが目にすることになります。また検索から記事を見つける人もいるでしょう。あなたの記事が読んだ人の役に立つかどうかを意識してみましょう。 自分用のメモのつもりで書いたものでも、少し気をつけるだけでぐっと価値のある記事にすることができます。 意識すると望ましいもの 具体的で簡潔なタイトルをつける 記事のタイトルは、記事のページだけでなくQiitaのフィードや検索エンジンの検索結果にも表示されます。タイトルを見
Greg Young流CQRS - Mark Nijhof - Digital Romanticism
この記事はMark Nijhof氏のブログ記事「CQRS à la Greg Young」を氏の許可を得て翻訳したものです。（原文公開日：2009/11/11） この記事は以前のブログである"blog.fohjin.com"にて公開していたものです。 以前、2日間の講習を受けた時に、ビールを飲みながらGreg Young氏とドメイン駆動設計について語るという幸運に恵まれたことがあります。その時の話題は専ら、コマンドクエリ責務分離（CQRS:Command and Query Responsibility Segregation）パターンに関するものでした。Gregは、Eric Evans氏が著作において説明したドメイン駆動設計を受け継ぎ、主に技術的な実装を進化させています。コマンドクエリ分離（CQS）は元々Bertrand Meyer氏によって考案されたもので、オブジェクトのレベルで適用さ
Cutting Edge - 一般的なアプリケーション向けの CQRS
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 一般的なアプリケーション向けの CQRS Dino Esposito ドメイン駆動設計 (DDD) は約 10 年前に登場し、ソフトウェアの開発者やアーキテクトに影響を与えています。具体的なメリットやデメリットはともかく、DDD は、オブジェクト指向パラダイムが初めて唱えられた頃、開発者の誰もが夢見たことを具体化します。つまり、包括的なオブジェクト モデルを中心にアプリケーションを構築して、すべての関係者の要件や懸案事項に対処するという夢です。 その後の 10 年、多くの開発者が DDD のガイドラインに従うプロジェクトに取り組んできました。成功したプロジェクトもあれば、失敗したプロジェクトもあります。実は、
私的実践DDD、その２ - たなかこういちの開発ノート
（※前回からの続きです。） CQRSはモデリング上の本質的な課題への対応である CQRS（Command-Query Responsibility Segregation、コマンド・クエリ責務分離）の採用は、現代的なシステムではほぼ全て必然的にそこへ帰結すると考えた方がよいと思います。CQRSという用語は「実践ドメイン駆動設計」を読むまで知りませんでした。というよりも、参照系と更新系を分離して設計しようという話をDDDが言及しているとは知りませんでした。しかし、下記記事で書いたように、要求・要件の分析観点から、参照系業務ロジックと更新系業務ロジックは非対称に構築すべきという点はむしろモデリング上の本質的な課題だとの考えを持っていましたので、CQRSはすんなり理解できました。 ※下記記事を参照してください。 《業務プロセス、業務ロジックの理解と、フロントエンド−バックエンド間I/Fの詳細》
エンジニアは無理して一発当てるより、コツコツと自分を指す『代名詞』を育てていったほうが良いのではないか？ - カラクリサイクル
mizchi.hatenablog.com id:mizchi さんのこの記事を読んで、自分なりに考えてみたことを書く。 ちなみに自分でも考えがまとまってるワケではないので、 妙な解釈やおかしなことを言ってたらすまんこ。 1. 何かを作って『一発当てる』というのは、その時々の情勢、時期、運のすべてが噛み合わないと、恐らくは出来ない まあ僕も野心というか、 何かを作って一発当てる というのは、自分の手で成し遂げたいコトではある、と思っているのだけれども、それは多分、 その時々の社会的情勢や要求といった時代背景 それを実現する上での技術課題の克服やそれを出す時の適切な時期の選択 それを上手く乗せるための時の運の手繰り寄せ みたいな事柄について、 すべてを巧く噛み合せる ことが要求されると思っている。 で、それが mizchi さんのブログ記事の前半で言われていること重なると思うんだけど、こう言
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
esa.io - 趣味から育てたWebサービスで生きていく
MonotaRO(モノタロウ)
次の10年のためにElixirをハックする
SlackinでSlackに誰でも参加できるチームをつくる - Qiita