ふざけんな！ごみの分別！
前々から思っていたんだが、ごみ処理は行政の仕事だろうが！ その一部を市民にさせるな 「プラでも汚れてるものは燃えるごみに出してください」 もっとふざけんな！分別の判断までこっちに押し付ける気か！ 時間と労力、精神的な疲労がどんなに溜まるかわかってんのか 「一人一人の意識が・・・・エコで・・・・・」 意識とかエコとかうるせーよ ただお前らがめんどくせーだけだろ 無駄な道路工事とか施設作る金があったら、ごみ処理場にもっと人雇えよ 失業者も減るしいい案だろ なんなら税率引き上げてもいい 貴重な時間と労力を金で解決できるんだ こんないいことはない 税金上がったら条件反射的にキレるバカとか、所得の低い底辺連中は怒るだろうけどな
Microservices Casual Talksに行ってきた - チラシ裏日記上等！！新館
オライリーの「マイクロサービスアーキテクチャ」の発売を記念したイベント、Microservices Casual Talksにマイクロソフトまで行ってきた。 マイクロソフトがマイクロサービスのイベントをやる。マイクロつながりだなと思った（雑）。 以下感想とかメモ。 マイクロサービスの事例 マイクロサービスの原則や、事例などを知ることができておもしろかった。Giltのマイクロサービスの例では最初はRialsのモノリシックなアプリケーションが、今ではPlayFrameworkによる数百個単位のマイクロサービスになっているというのが衝撃的だった。AWSのt2.microのインスタンスを大量に立てているというのがおもしろかった。 Giltについては以下のページが参考になる。 www.infoq.com SoundCloudの例では大きなマザーシップなアプリケーションはそのままにして新しい機能をマイ
マイクロサービスアーキテクチャへの取り組み - ハマログ
はじめに ”マイクロサービスアーキテクチャ”という言葉も、随分普及してきました。 イーツー・インフォでも取り組みをおこなっているため、おさらいしてみます。 マイクロサービスアーキテクチャとは ひとつのシステム内で必要なすべての機能を実装するのではなく、ある程度の機能単位に分割したシステムをそれぞれ構築し、互いに連携させるアーキテクチャのことです。 前者をモノリシック(monolithic：一枚岩)、後者をマイクロサービスと呼びます。 2001年宇宙の旅とかエヴァンゲリオンとかゼビウスなどに登場する、あのモノリスです。 図：The monolith as it appears in 2001: A Space Odyssey wikipedia(en)より 図：マイクロサービスで構成されたシステム 言語定着のきっかけは、かの有名なMartin Fowlerの以下の記事と言われています。 Mi
【速報】成宮寛貴を売ったA氏を特定完了
成宮寛貴のプライベートを週刊誌に売って芸能界引退に追い込んだ挙句、アフィリエイトで儲けようとしているA氏の正体を掴むことに成功した。 特定に至るまでの経緯について順を追って説明する。 「成宮寛貴の友人A氏」と名乗る人物がTwitterに現れたのは12月14日22時47分のことだった。 今でこそ有名になったこのアカウントは当初誰が拡散したのか。netgeek編集部はまず第一発見者を洗うべきという捜査の基本に基いていち早く拡散した人物を調べた。 A氏の初投稿からわずか9分後の22時56分、真月ブルシ（@YYib3ggd）という人物が「A氏現る」というコメントとともにキャプチャ画像を投稿していた。 この真月ブルシという人物を詳しく調べていく。FacebookやブログもやっていたのでA氏に繋がる画像がないか探っていくことにした。 探すポイントはA氏がテレビに出演した際に得られた外見、身体的特徴を押
より良いデザイン批評をするための質問
デザイナーや開発者であれば、アプリや Web サイトを見ると何かしらリアクションがあると思います。「かっこいい」「面白い」「使いやすい」といった感想は、口に出さなかったとしても考えることです。第一印象から生まれる感覚は大事ですし、常に身の回りにあるデザインに意識を向けることは良いことです。しかし、そうした感情的なリアクションがデザインに対する良い批評にならないことがあります。 批評やフィードバックは、現行のデザインをさらに良くするために行われます。「これは使いにくい」はひとつの感想ではありますが、次のステップのための道筋とは言えません。それが誰にとって、なぜ使いにくいのかを共有しないままでは意図が伝わっていないようなものです。むしろ、使いにくいものを作ってしまったデザイナー個人への批判に聞こえてしまう恐れもあります。デザイナー自身も、すべてのフィードバックが個人に向けられているものではない
（私的雑記）対人関係は苦痛です - 解き放たれしソフトウェア
趣旨 何が言いたいかを先に言うと、私は他人と関わると萎縮して聴く側にしかまわれなくなる人なので、対人関係が楽しいことはほぼ皆無です。話すべきことを話さねばならない、話したいというときには、独りで書いて公開すればよいし、そうするしかありません。 他人に絡まれずに書かねばならないという人がいるという認識が社会には無いのでしょうか？ 私に絡んでこないでほしいし、絡まれないウェブサービスを私は求めているんです。 書いて公開する、成果物を出すことが目的であって、他人と仲良くすることは求めていないんです。 ところが Twitter はおろか GitHub にもそれが欠けています。だから私は、これらを使えない。 Advent Calendar が始まったが December of this year has come. 例年と同様に主に2箇所で Advent Calender の投稿が始まっています。
チーム開発の開発環境として Docker + Vagrant を選択し続ける理由
チーム開発の開発環境として Docker + Vagrant を選択し続ける理由 Docker Advent Calendar 2016 の 25 日目です. Docker アドベントカレンダーとして書いているはずだったんですが、推敲と校正を重ねているうちに Docker というよりは VM とか開発環境とかの話が色濃くなってしまい、主役のツールが Vagrant になってしまいました. 謹んでお詫び申し上げます. 僕が所属する会社の事業の一つに Web/モバイルアプリの SI + 運用があり、その際の Web/API サーバー開発は macOS + Vagrant + VirtualBox (CoreOS) + Docker を社内標準のローカル開発環境(以下、開発環境)としています. 勉強会後の懇親会やコンサルティングを提供する場で良く質問されることの一つに「Docker for Ma
クライアント主権時代にJSのモデルはどう共有すればいいのか - Qiita
SPA、スマートフォンアプリの隆盛。時代はクライアントサイドに主権が移ってきている。 これからの時代はクライアントサイドにロジックを持たねばならぬだろう。 一方サーバーは、「ユーザー１人でも完結するサービス」に限れば、 DOA(Data Oriented Architecture)的な立ち位置のもの(≒mBaaSとか)と、BFF(Backend for Frontend)的な立ち位置のものがあればよくなる。 モデル定義がダブる いままでモデルはサーバーのものだった。 クライアントでは「JSON」というデータになってやってきて、 それをなんとなく成形して表示してた。 でも来るべきクライアント主権時代においては、 やっぱりクライアントでもJSONじゃなくてドメインモデルを扱いたい。 そうするとサーバー/クライアントの2つの環境でモデル定義を書かなくてはならないではないか。 多くのサービスは実は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
