「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証

6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに本日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社

日頃お世話になっている皆様へのお知らせです。なるべく多くの方に直接お伝えしたかったのですが、この場でのお伝えになってしまった方には申し訳ありません。 はてなを退職します。4/17(水)が最終出社でした。所属は5/31(金)までです。 ずっとはてなで働きたいと思っていましたし、この絶好のタイミングで辞めてしまうのは勿体無いという気持ちもあります。ただ、次の挑戦に関して時間的な制約もあったため退職させてもらうことになりました。この詳細はまた別途お知らせできればと思っています。 2014年に現在のはてな東京オフィスの一人目のエンジニアとして入社し、その後、チーフエンジニアと、Mackerelのプロダクトオーナー(マネージャー)を兼務してきました。 チーフエンジニアとして組織に、Mackerelではプロダクトとビジネスに関わりました。入社当時、私一人だけだった東京オフィスのエンジニアも今では二桁に

この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい

インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0

少人数でサービス開発をしていると、サーバーのアカウント管理を疎かにしてしまいがちです。良くないことだとわかっていながらも、共用ユーザーのログイン情報を数人で共有していたりだとか、rootばかり使っているなんてこともあるのではないでしょうか。 それだとオペレーターが増えたり、退職者がでたりした時に困ることになるので、最初からルールと仕組みを決めておいた方がトータルで楽になります。 前提 パスワードやログイン鍵の共用、ダメ！絶対！ rootを常用するの(・A・)ｲｸﾅｲ!! パスワードやログイン鍵を共用していると、人数が増えた時に誰が作業しているのか把握するのが大変になりますし、退職者が出た時に一斉変更をせざるを得なくなって混乱してしまいます。逆に一部のスタッフを別扱いして権限を制限したユーザーをアドホックに作ったりしてしまうのも管理が煩雑になります。じゃあどうすればよいかというと、個人ごとに

この記事はPerlアドベントカレンダー2014の記事ではありません。 nihenさんのやつをベースに改変しました。 DBIx::Sunnyを加えてみた。DBIx::Sunny::Schemaという隠れた便利機能を使ってみた Skinnyは外そうかと思ったけどちょっと驚きの事実があったので残した https://gist.github.com/Songmu/989f10b2525523914de8 DBI: 1.631 DBIx::Class: 0.082810 DBIx::Skinny: 0.0742 Teng: 0.26 DBIx::Sunny: 0.22 --- insert --- Rate dbic teng skinny sunny dbi dbic 2983/s -- -16% -72% -78% -92% teng 3565/s 19% -- -67% -73% -91% s

あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ

Perlで単一ファイルのスクリプトを書くと、すぐに配置して動かせるので重宝しますが、テストを書きづらいのが難点です。 ちゃんとpmファイルに分割して云々とかやると単一ファイルで動かなくなるし、かと言ってfatpackするのもちょっとした用途だったらやり過ぎだしめんどくさい。 ということで以下のように書いてはどうか。 if ($0 eq __FILE__) { main(); } sub main { ... } $0に実行ファイル名が入っているので、それがスクリプトファイル名と一致していたらmainの処理を実行する。pythonのif __name__ == '__main__':みたいな感じ。 このスクリプトをテストしたいときは、普通にテストスクリプトを書いてrequire 'main.pl';とかやれば、plファイルの中で定義されている関数とかが個別に呼び出せるのでそれをテストしてやれ

http://yapcasia.org/2014/talk/show/e10a7e62-01ba-11e4-b7e8-e4a96aeab6a4 今年のYAPCはPerl以外の言語に関するトークが多く応募されています。それ自体は多様性の観点から悪いことではないし、Perlを触っている側からしても、Perlと比較しながら他言語について知ることができるのは有意義だと感じています。 ただ、これはPerlを共通言語として他言語を理解しようという流れだと思います。つまり、Perlというコンテキストが共有されていることが前提になっているのです。 翻って、今年のYAPC::Asiaの様相を見てみると、実はそんな「コンテキスト」なんて共有されてないのではないかと感じられます。 今年のYAPCはPerlを使っていない人もたくさん来場されそうだし、それに、YAPCに来る大半のPerl初級者・中級者にとって、日々

http://togetter.com/li/673629 こういうふうにまとめてくださっていたのですが、自分なりの考えの補足など。 上記でも言及している、「俺のオレオレgit-flow」というエントリにも書きましたが、この運用で進めてみて結構良かったなーと思っている。その辺に関しては以下のツイートしたりした。 masterでQA通してからreleaseブランチにマージしてdeployって感じすなー。 — songmu (@songmu) 2014, 5月 30 ゲームだと画像内の文字の表記間違いとかをやらかすだけで、その事後対応でプログラマの稼働が下手すりゃ一日飛ぶので、master直deployは怖いので、並列でreleaseブランチを走らせて、そっちにマージしつつdeployしてる。 — songmu (@songmu) 2014, 5月 30 masterからreleaseへのマー

勝手に添削: Test::mysqldとTeng::Schema::Dumperを使ってTengのSchemaクラスを自動生成する 〜Daiku編〜 http://masteries.papix.net/entry/2014-05-19-teng-schema-dumper.html Daikuをご利用いただきありがとうございます。上記のエントリーに関して以下の様な点が気になりました。 Daikufileを太らせるのは良くない せっかくのDSLなのにコードがゲロっと書かれてしまうのは残念な感じがする あくまでコード例なので、対策はしているのかも知れませんが、僕だったらこうするというのを書きます。 概要は以下のとおりです。 task用のパッケージをつくる Daikufileからはそれを利用する パッケージは以下のようになります。 package MyApp::CLI::DumpSchema;

MySQL::Partitionをリリースしていたのでお知らせです。パーティションを切る用のSQLを生成してくれるクエリビルダーです。 Webサービスでは如何にデータを増やさないか、DBを分割しないで一系統に抑えるか、DBをメモリに如何に載せきるかってのがゆるふわサービス運用をしていく上で重要です。MySQLを使っている場合、そのために非常に有用なのがパーティションで、適切にパーティションを切り、古いデータを随時Dropしていける運用に落としこむのが非常に大切なわけです。 社内のプロジェクトでもPartitionを活用しているわけですが、いまいち仕組み化されておらず、古いプロジェクトからコピペを重ねて秘伝のタレ化しており、例えばデイリーでパーティションを切る場合、MySQL5.5からはRANGE COLUMNSパーティションが使えるにも関わらず、TO_DAYS()とかを未だにコピペして使い

Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通