本年も高橋会長を囲んで一年の労をねぎらいましょう。 日時 12/13(土) 18:00 場所 北の味紀行と地酒 北海道 上野広小路店 「ヨシダ」で予約しております 不明点は @hrysd までご連絡ください 予算 5270円 飲み放題付きのコースとなっております。 前売り券のみとさせて頂きました。ご了承ください。 キャンセルについて キャンセルしたいという方は12/06(土曜日) 18:00 までにお問い合せフォームからご連絡いただくようお願いします。 それ以降のキャンセルについては、ご返金できない場合がございますのでご容赦ください。 突然のキャンセルの方がおられた場合、その方のぶんを他の参加者の方で割り勘にさせていただきますのでご容赦ください。

■ Kindle Voyageが届いたのでさっそく自炊本の最適化をする 1年ほどまえから「物理ボタンが復活したKindleが出る」という噂があって、いまかいまかと待っていたら、発表されたVoyageは物理ボタンじゃなくて圧力センサだったけど、解像度もあがってかなり良さそうなのでさっそく予約。今日届いた。フラッグシップ機だけあって、けっこういいお値段: Kindle Voyage、電子書籍リーダー、Wi-Fi - Amazon (no price) たしかこれまでに買ったKindleは殺風景なダンボール製の箱に入っていたのに*1、いつのまにかずいぶん小綺麗なパッケージになったんだなぁ。箱のサイズはほぼ本体と同じでかなり小さい。厚みのほとんどがUSBケーブルの分(笑): Kindle Keyboard、Kindle 4と並べてみた。もちろんVoyageがもっとも小さくて、それでいてもっとも速く

インフラストラクチャー部の宮下（@gosukenator）です。 クックパッドでは一部のサーバで Ubuntu を使い始めており、 apt リポジトリをどのように管理するのが良いのか、試行錯誤しています。aptリポジトリ管理で実現したいことは、主に次の2点です。 自前でビルドしたパッケージの管理 リモートリポジトリから削除された旧バージョンパッケージの保全 このあたりをいい感じにできるツールはないかな、と社内で話していたところ、カルビ生焼け王 に教えてもらったのが aptly です。 aptly とは 公式サイトに「aptly is a swiss army knife for Debian repository management」とあるように、aptly は多機能な apt リポジトリ管理用ツールです。外部リポジトリのミラー作成、ローカルリポジトリの作成、リポジトリのスナップショット

Google Cloud Platform (GCP)の話を肴にピザとビールをいただく会です。今回もフリークアウトさんの会場をお借りして、@masuidriveさんのBQ+GAS話や、@yuguiさん@stanakaさんによるKubernetes話、そしてBigQueryを1年以上実運用で使われてきたセブン＆アイ・ネットメディア中村さんの事例を聞きます。GCPユーザーグループ設立のお知らせもあります。参加費は無料！（今回は応募方法を抽選にしてみました） セッション 7:00pm: トレタのBigQuery / Google Apps Script活用術 by @masuidriveさん 昨年7月に創業したトレタでは、顧客に提供している「トレタ」アプリは、iOSのネイティブアプリとRailsを使ったバックエンドで構成されています。各種集計ツールや社内の社内で使うツールはGoogle Apps

This document provides an overview of React, including initial reactions to it, fundamental concepts like components and one-way data flow, and how the virtual DOM works. Some key points covered include: - Initial reactions to React were mixed, with some finding it "ugly" but others seeing benefits like separation of concerns with components. - Everything in React is a component, with data flowing

2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU

先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528

今教えてもらった。知らなかった。もしかしたらちょっと便利かもしれない。 サファリでmuninとか開いて「ファイル」 ->「Dashboardで開く」を選択する。 で、選択して、追加をクリック。 するとこんな感じで、ダッシュボードで見れるようになる。ついでにアメッシュも表示させてる。よく見るグラフをダッシュボードに入れておけば、四本指スワイプで「シュッ！」で見れるようになる。 おわり

なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか？画面にボタンが多いほど、マニュアルが厚いほど初めてのユー