ssig33.com - Scrapbox Drinkup #4 にいってきた
ブログ枠ということなので書く。 Scrapbox 個人ではあんま使ってないのでここに書きます。 Scrapbox Drinkupへの参加の感想を1週間後までに書いていただき、インターネットに公開していただけることが条件になる枠です とあるのがどういうふうに書けとは指示がないのでそのように行なわれるでしょう。各セッションの細かい内容などはイベントの Scrapboxを参照されたし。 サポートチケットから Scrapbox のページが作られるという話について思ったこと これに関して、使っているツールは Slack なのだけど僕が働いている会社でも同じようなことをやっていて大きな成果が出ていると考えている。 サポートチケットそのものとは別の場所にコミュニケーションのための場があるのは極めて良いことであると思う。 Nota 社の取り組みのうちユビレジの取り組みより進んでいると感じたのは、対応用ペー
ssig33.com - DeNA TechCon 2018 『『Nintendo みまもり Switch』を支える技術』 の内容紹介と感想
そういうわけで https://techcon.dena.com/ にいってきました。 表題の発表は、撮影および SNS での内容共有の禁止ということになっていたので、内容を個人サイトで共有致します。その場にいなかった方でこの記事を読んだ方であればこの記事およびその内容を SNS で共有することは一切禁じられないかと思いますのでよろしくお願いします。 発表者 DeNA 堀、平賀 任天堂 名前メモし忘れた 公開されたスケジュールでは堀および平賀による発表ということになっていたが、任天堂の何者かが急遽参加したということだった。おそらく技術者ではなく広報の人。 サービス紹介 (任天堂の人) サービス内容については検索すれば分かることを普通にしゃべり、クッパがサービスを使うあの動画を流すだけ。(ssig33 の感想: なにしにきたんだコイツ) 開発体制 (堀) 任天堂は企画、ディレクション、 Sw
ssig33.com - 最悪！意地でも Heroku を無料で使う
Heroku は最近料金体系に変更があって、無料では一日 18 時間までしかアプリを起動できなくなりました。 自分専用のアプリとかそういうものなら全く問題はないのですが、それなりにユーザーがついているようなアプリだとなんだかんだで 24 時間 Dyno が起動しっぱなしということはおおいと思います。 一番安いプランは 7 ドルで、とりあえずこれだけ払えば 24 時間 Dyno を起動しっぱなしにできます。 公開しているアプリが 1 個ならまあ 7 ドルぐらい払っとけよで済む話なのですが、私のように 18 時間制限にひっかかってるアプリが 30 個もあるとなると 210 ドルを払うのは躊躇してしまいます。 ということで今日は石に齧りついてでも Heroku をタダで使う方法を考えていきます。 基本的なアイディア Heroku でアプリ 2 個用意して、同じ DB 向くようにして、 12 時間
ssig33.com - docker ホストを長期間運用する際の注意点
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
ssig33.com - エンジニアならこれ読んどいた方がいいみたいな本
失敗学 (図解雑学) 賢者は歴史に学び、愚者は経験に学ぶという。その仮定が正しい場合、人類の知能はそこまで広く分布しているわけではないので人類はだいたいみんな歴史からは学べないということになる。 正直自分の実感としても他人の失敗事例から学べたということは少なく(歴史から学ばない態度)、人は自分の失敗から学ぶしかないのではないかと思う。ただまあ他の技術者が事故にどのように対処したかとか、対処に失敗したかとか、歴史から学べた稀有な事例は何かといったことを読むのは楽しい。 爆笑問題のハインリッヒの法則―世の中すべて300対29対1の法則で動いている (祥伝社黄金文庫) ハインリッヒの事故防止の研究とは何の関係もないけど、爆笑問題カーボーイが一番面白かったころの本。今読んでも面白い。 Web業界 受注契約の教科書 Textbook for Business Contracts in the Web
ssig33.com - 最近買ったすごくいい服
これ マッキントッシュ フィロソフィーのトロッターシリーズ 一見ただのスーツなんだけど、ジャージ素材でできてて、着心地は完全にジャージ。 ジャージを着て外出することは通常最寄りのコンビニまでしか許されていない(佐賀県民や群馬県民、栃木県民はもっと遠くまで外出することを特別に許可されている)のだけど、これを着ていると本当にどこにでもジャージで外出することが出来る。 ジャージを着ていると本当に楽なので便利。ネックはちょっと価格が高い。ジャージでどこにでも行きたい人には本当におすすめです。 ジャージ素材なので家庭の洗濯機で洗うことができて、しかもそうやって洗濯しても全く型崩れしないのも便利。 しかし一つ問題があって、 IT 技術者は見た目で他人を差別するレイシストが多いのでスーツを着ているとバカにされる場合がある。そのあたりは適宜やっていきましょう。 back to index of texts
ssig33.com - Jenkins で Rails アプリを docker build する話
Rails アプリを Docker で稼動させる際に、 Gemfile と Gemfile.lock を先に ADD して bundle install してからアプリケーション全体を ADD することで、 bundle install の結果をキャッシュする手法はよく知られています。 ADD Gemfile /app/Gemfile.lock ADD Gemfile /app/Gemfile WORKDIR /apps RUN bundle -j4 ADD . /app こういうやつ。 ところがこの手法は Jenkins のように毎回リポジトリが clean にチェックアウトされる環境では全く無効です。 何故なら、 Docker は ADD するファイルが更新されているかどうかを、ファイルの中身そのものではなく、タイムスタンプなどのメタデータで確認しているからです。 git checko
ssig33.com - YAPC Asia 2014 行ってきた
行ったらブログ書けって言われたので。 HUB のビールはおいしかった HUB のビール以外もたぶんおいしかった あとはだいぶ記憶がない 会場の入り口に HUB があるというのは致命的な脆弱性で、まずは駆けつけ一杯みたいな感じでビールを沢山飲んでからトークを聞くみたいになってしまう。結果としてトークの内容を全然理解できないで帰ってくることになる。というかいつどうやって会場をでてどうやって帰ってきたのかとか全然記憶が無い。 とはいえなんかもう Perl の話はあんまりなくて、いろんな言語にまたがるふわっとした話が多い感じだったのでそんな感じの参加態度でいいかなとか思っている。 Web 開発もモバイル開発も思想は完成されていて、あとはどう大トラフィックに耐えるかとか、思想の実践をいかに洗練させていくかみたいな状態になっているのでまあふわっとした話が多いのはそういうことだと思う。しかしそうやって油
ssig33.com - 旅と在宅勤務
2 年間以上在宅勤務しています。会社から借りた MacBook Air はとっくにぶっ壊れて適当に放置されています。 2 年間のうち自宅にいた日数が 365 日に達しているかどうか分からないレベルで旅行その他をしてきました。 生産性は確実に落ちます 家でそれなりの机と椅子もしくは無印ダメソファで仕事をする場合の生産性は非常に高いものです 一方アジアのよくわからん所や不安定な衛星回線しかない飛行機や船の上で仕事をする場合生産性はそこまで高くありません そのようにまあムラは出るのですがそこまで含めて自分の生産能力だと会社に認めてもらえるかどうかという問題になってきます。 あとまあそういうふざけたことをしてるのを同僚に認めてもらえるかどうか。 環境にロックインされます 好き勝手どっかいきつつクリティカルな責任は会社に背負ってもらいつつ 500 万とか 600 万とか貰ってみたいなことが出来る環境
ssig33.com - IT 企業のオフィスを子供っぽい雰囲気にする
という言い方が最も適切かどうかは別として、比較的頻繁に執り行われております。内装をそんな感じにするとか、中学高校っぽい部活やるとか。 で。そういうのいいですねみたいな声が大きいので、そうなっていく IT 企業が多いのですが、 ガキっぽいエンジニアは声が大きい というだけで、 優秀なエンジニアは子供っぽい というわけでは絶対にないと思います。子供っぽいオフィスを用意しとけば優秀なエンジニアが集まるかというとそうではなくて、それで逃げていく優秀なエンジニアも確実にいます。 優秀なガキっぽいエンジニアみたいのがいないというわけではないですから、そういうタイプの人とそうじゃない人が住みわけられるようなオフィス設計というのがあってもいいのではないかと思ってます。 こちらからは以上です。 back to index of texts Site Search
ssig33.com - Docker をプロダクトのデプロイに使う
コミケの列に並んでたあたりのころから Docker 本格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ
ssig33.com - ダンピングをするな
これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「～を厳守する」という心構えが出てくる。ファイルを zip
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ssig33.com - アレです
ssig33.com - 東亜飯店に行ってきた
ssig33.com - 初心者が２ヶ月でプログラミングをマスターする方法
ssig33.com
ssig33.com - Webプログラマーを志す学生さんが、学生のうちにやっておきたい11の事