ssig33.com - Scrapbox Drinkup #4 にいってきた
ブログ枠ということなので書く。 Scrapbox 個人ではあんま使ってないのでここに書きます。 Scrapbox Drinkupへの参加の感想を1週間後までに書いていただき、インターネットに公開していただけることが条件になる枠です とあるのがどういうふうに書けとは指示がないのでそのように行なわれるでしょう。各セッションの細かい内容などはイベントの Scrapboxを参照されたし。 サポートチケットから Scrapbox のページが作られるという話について思ったこと これに関して、使っているツールは Slack なのだけど僕が働いている会社でも同じようなことをやっていて大きな成果が出ていると考えている。 サポートチケットそのものとは別の場所にコミュニケーションのための場があるのは極めて良いことであると思う。 Nota 社の取り組みのうちユビレジの取り組みより進んでいると感じたのは、対応用ペー
ssig33.com - Docker で Go で作ったバイナリを実行するなるべく小さいコンテナを作る
Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい
ssig33.com - Rails のコントローラーテストをインテグレーションテストに最低限の手間で移行する
Rails 5 がリリースされました。多分目玉としては ActionCable の導入なのですが、既存コードベースのアップグレードに関して一番重要な問題は、コントローラーテストが廃止されるというものになるのではないでしょうか。 というわけで気持ちになってやっていきます。 一般的に今でも Rails のテストの記述には RSpec が用いられることが多いのではないでしょうか。僕も以前 RSpec の記法のメリットについて書きました。ですが私達のチームでは RSpec ではなく test-unit を使っています。理由としては RSpec のマッチャーとかの記法がヤバくなった(こういう話) xUnit のアサーションの方が書きやすくね?という RSpec の context は確かに強力な機能だが実際には特に生かされていなかった RSpec のメンテナのアイコンがキモい というわけですから私達
ssig33.com - なぜ SPA か
顧客は SPA であることを望んでいるのか？そうではないです。技術者は SPA を作りたいのか？そうではないです。 ではなぜ SPA 的なものが出来てしまうかといえば、いちいち UI の遷移のために大量のデータをロードしているのは時間と資源の無駄だからです。 もちろんあるべき姿としては、サーバーの CPU やストレージやメモリは爆速で、回線も爆速で、用いられるデータは必要最低限で、クライアントマシンも爆速で、クライアント側でフォームを一個書き換えるたびにページをフルロードしても全くストレス無く使える、というような世界観です。 しかし実際にはサーバーのスペックも回線もクライアントのスペックも不足気味ですから頑張って補っていく必要があります。 すると最初にロードしたデータをクライアントは保持し続けて、 HTML 全体を書き換えるのではなく必要なところだけを最小限の通信とともに書き換えてみたいな
ssig33.com - バーベキュー
そういうわけですから、今日はバーベキューに取り組みます。長い記事を読まない皆さんの為にとりあえず完成したものを共有したいと思います。 バーベキューはゴールデンウイークの娯楽としては極めて一般的です。僕は普通の人間なのでバーベキューをします。 まずはバーベキューとは何かという問題について考えていきます。最初に以下の画像をご覧ください。 左は単なる外でやる焼肉、右は美味しそうな食べ物であることが一目瞭然です。我々は右を目指さなければならない。 そこでいくつかバーベキューの定義を調べてみると、バーベキューラブやらなんらかのソースやらを揉み込んだ肉を長時間グリルで蒸し焼きにしたものがバーベキューであることが分かります。 肉が焼き上がったあとにこれでもかというほどソースを塗るのがテキサス風というイメージが僕のなかではなんとなくありましたが、あれは焼き上がりから提供までに時間がかかるバーベキュー大会や
ssig33.com - 2ch のアレ
robots.txt は法律上以下のようになってます。 無視してクロールしてもいいけど、無視してクロールした結果を公開するのはダメ つまり新 2ch では以下のようなサイトが法律上 NG になります API キーをアプリから解析して新 API 勝手に使ったりクロールしたりして過去ログ公開するようなサイト 上記のような仕組みで旧 2ch っぽいインターフェイスを提供するプロキシサイト 上記のような仕組みで動作する Web アプリケーション型 2ch クライアント OK なのは以下の行為です スクレイピングして動作するデスクトップ、携帯電話向けのクライアントを開発、配布する 無論、これらのクライアントが常軌を逸した動作をして、結果 2ch のサービス継続を妨害するようなことがあれば、 2ch は民事、刑事で適切な対応を取ることができるでしょう。この場合参考になるのは librahack 事件で
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
ssig33.com - エンジニアならこれ読んどいた方がいいみたいな本
失敗学 (図解雑学) 賢者は歴史に学び、愚者は経験に学ぶという。その仮定が正しい場合、人類の知能はそこまで広く分布しているわけではないので人類はだいたいみんな歴史からは学べないということになる。 正直自分の実感としても他人の失敗事例から学べたということは少なく(歴史から学ばない態度)、人は自分の失敗から学ぶしかないのではないかと思う。ただまあ他の技術者が事故にどのように対処したかとか、対処に失敗したかとか、歴史から学べた稀有な事例は何かといったことを読むのは楽しい。 爆笑問題のハインリッヒの法則―世の中すべて300対29対1の法則で動いている (祥伝社黄金文庫) ハインリッヒの事故防止の研究とは何の関係もないけど、爆笑問題カーボーイが一番面白かったころの本。今読んでも面白い。 Web業界 受注契約の教科書 Textbook for Business Contracts in the Web
ssig33.com - ファイルダウンロード自動化を含むスクレイピング
なんのこっちゃという感じですが、具体的にやりたいことは以下の通り Amazon の コンテンツと端末の管理 から購入した Kindle 書籍を自動ダウンロード 何故こんなことをしたいかというと、 Kindle 本は DRM をクラックする確実な手段があります。 DRM をクラックすることは違法ですが、 Amazon という企業が消滅した時に、購入した本が読めなくなるのは困ります。 Amazon が消滅するときは世紀末のような社会でしょうから、 DRM のクラック程度の犯罪が問題になることは無いでしょう。 AZW3 をローカルに保存しておけば、その時がくれば DRM をクラックすればいいということになります。 以上の考えは半分本気、半分はまあスクレイピングしづらそうなものがあればやってみたい、というだけです。 JavaScript を含まないページのスクレイピングはどうとでもなります。 Ja
ssig33.com - 退職時に古巣に砂をかけるべきではないのかという問題
結論: 程度問題だし個別に判断しろ この辺に関する話 http://mizchi.hatenablog.com/entry/2013/09/07/171644 http://shunirr.hatenablog.jp/entry/2013/07/01/000944 http://d.hatena.ne.jp/gnarl/20120407/1333725733 退職時に古巣に後ろ足で砂をかけるようなブログ記事をかけるような人達がいる。それに怒っている人達がよくいる。という訳で個別の事例について考えていきましょう。 mizchi 技術力はそこそこある。人格は糞。月給 24 万とかだったらしいし 24 万が新卒として安いかというと、まあ安くもない。絶対的に人的資源としての価値だけ考えれば多分微妙に安い。彼は「成果」を主張しているが結局あの地獄の JS プロジェクトそんなに売り上げたってないっぽい
ssig33.com - 運営と技術者の距離を近くして開発効率を上げよう！！！
みたいの結構良さそうな感じがするんですが。実際そうではないです。 運営はユーザーからのクレームやサービスの問題点を大声で議論をします。エンジニアは大抵気が弱いので四六時中聞かされていると会社を辞めてしまいます。 また運営は四六時中エンジニアから「そんなこと言いますけどそれ実装するの無理です」と言われ続けますからストレスで会社を辞めてしまいます。 そうして誰もいなくなる。残るのは悪意に鈍感なウスノロだけでそんな奴は使い物になりません。なので大抵の場合運営と開発はある程度物理的に距離をとってしまうほうがよいです。 ですがまあ距離を近くしよう的な策が取られることが多いです。これは何故かというと、「企業家」「経営者」といった連中は上記のような地獄をとおりぬけてきた人間や、それをなんとも思わないような人間だからです。その辺こういう話に近いと思います。 雇われてるだけの人間は精神壊す前に逃げましょう。
ssig33.com - ネイティブアプリ並のウェブアプリを云々
なんか最近そういうの流行ってるようですね。僕も考えを書いてアクセス数を稼ぎます。 ページ遷移を過度に抑えようとするな 下手に AJAX 使いまくるぐらいならページ遷移したほうがマシであることが多いです。世の中にはページ遷移を抑えようとして酷いことになってる JS を沢山見ます。よく考えろ。 ローカルストレージを活用しない localStorage に画像とか放りこむの異常に重くなるのでオススメしません。認証持たないサービスで設定値保存するのに使うとかに留めた方がよいと思う。 非同期な API 絶賛してて気に食わない感じはしますがこの記事を一読することをお勧めします。 localStorage は小さなデータをいくつか入れる分には十分に高速です。大きなデータを入れると十分に低速です。 scroll イベントに対してリスナーを置かない scroll イベントの監視は実際最悪のアイディアです。こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ssig33.com - アレです
ssig33.com - 東亜飯店に行ってきた
ssig33.com - MacBookAir 買ったらスグ入れたい！エンジニア必携ツール1個