ssig33.com - アレですそんな感じです。 Web アプリケーションエンジニアが欲しい人いたら連絡ください。インフラまわりと UI 関連でいろいろできます。 mail@ssig33.com 090-1450-2501 back to index of texts Site Search
ssig33.com - YAPC Asia 2014 行ってきた
行ったらブログ書けって言われたので。 HUB のビールはおいしかった HUB のビール以外もたぶんおいしかった あとはだいぶ記憶がない 会場の入り口に HUB があるというのは致命的な脆弱性で、まずは駆けつけ一杯みたいな感じでビールを沢山飲んでからトークを聞くみたいになってしまう。結果としてトークの内容を全然理解できないで帰ってくることになる。というかいつどうやって会場をでてどうやって帰ってきたのかとか全然記憶が無い。 とはいえなんかもう Perl の話はあんまりなくて、いろんな言語にまたがるふわっとした話が多い感じだったのでそんな感じの参加態度でいいかなとか思っている。 Web 開発もモバイル開発も思想は完成されていて、あとはどう大トラフィックに耐えるかとか、思想の実践をいかに洗練させていくかみたいな状態になっているのでまあふわっとした話が多いのはそういうことだと思う。しかしそうやって油
ssig33.com - はてなブログ遅い話
これ http://emija.hatenablog.com/entry/2014/03/11/231940 の話です。 Web のパフォーマンスは我々の共通の懸案ですから、真面目に考えていきましょう。 当該 URL で調査 広告オン時 Adblock した時 いずれもキャッシュ無効です。 結論 広告ベタベタ増やしてる + WiMAX のルーター置いてる場所がなんかダメなのが悪いんじゃないの？ 参考資料 読み込みに使ってるページはこれ http://blog.livedoor.jp/dqnplus/archives/1790719.html 痛いニュース広告オン 痛いニュース Adblock なんとなくブログ界隈全体が表示遅いんじゃないかという気がしますね。 ちなみに以下はうちのサイト さらにいろいろ調べた結果 ブログだいたい Adblock して 4 秒ぐらいで表示されてしてないと 8
ssig33.com - ダンピングをするな
これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「～を厳守する」という心構えが出てくる。ファイルを zip
ssig33.com - Docker をプロダクトのデプロイに使う
コミケの列に並んでたあたりのころから Docker 本格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ
ssig33.com - 運営と技術者の距離を近くして開発効率を上げよう！！！
みたいの結構良さそうな感じがするんですが。実際そうではないです。 運営はユーザーからのクレームやサービスの問題点を大声で議論をします。エンジニアは大抵気が弱いので四六時中聞かされていると会社を辞めてしまいます。 また運営は四六時中エンジニアから「そんなこと言いますけどそれ実装するの無理です」と言われ続けますからストレスで会社を辞めてしまいます。 そうして誰もいなくなる。残るのは悪意に鈍感なウスノロだけでそんな奴は使い物になりません。なので大抵の場合運営と開発はある程度物理的に距離をとってしまうほうがよいです。 ですがまあ距離を近くしよう的な策が取られることが多いです。これは何故かというと、「企業家」「経営者」といった連中は上記のような地獄をとおりぬけてきた人間や、それをなんとも思わないような人間だからです。その辺こういう話に近いと思います。 雇われてるだけの人間は精神壊す前に逃げましょう。
ssig33.com - OpenFastladder が現代的な環境で動くようになってきてる
表題通りの話です。 Fastladder これ Rails 2.0.2 とか絶望的に古い環境でしか動かなかったんですが。昨日一日で結構いろいろやりました。 Ruby 1.9.3 + Rails 3.2.12 という近代的な環境で動きます。 ユーザー作成 ログイン フィードの登録 クロール 各種設定の変更 閲覧 は「とりあえず」動いてます。今のところ動いてないことがはっきりしているものは OPML のインポートとエクスポート ライブラリが 6 年近くアップデート止まってて結構辛い です。週末中に OPML はなんとかします。クローラーがかなりアレなのでこれで提案されてるクローラー向け API もさくっと作ってしまおうと思っています。 「どうぞ、ご利用ください」と言えるような品質にはまだなってませんが、ご利用 & pull req くれると嬉しいです。 以下駄文。 ソーシャルフィルタリングある
ssig33.com - ネットアイドルじゃない
そういえばフバさんがつつみともよって人を説明する時に「高専界隈でネットアイドル化してる人」って言ってたんだけど、すごい適当な説明だった気がする — 竹達彩奈(ビッグマン 4L) (@ssig33) October 2, 2012 酒抜けた今でもきわめて appropriate な表現だと思う — パソコンマシーン太郎 (@fuba) October 2, 2012 @ttmtmy ネットアイドルなんですか? — 竹達彩奈(ビッグマン 4L) (@ssig33) October 2, 2012 @ssig33 違いますし妹と同じこと言わないでください… — tutumitomoyo (@ttmtmy) October 2, 2012 @ttmtmy 申し訳ありません… — パソコンマシーン太郎 (@fuba) October 2, 2012 うちのいもうとが 「おねえちゃんはアイドルになりた
ssig33.com - ベンチャーについて極めて基本的なこと
本当に基本的なことを書きます。これから書くのは本当に基本的なことです。ですが以下のことへの理解が足りない事例をよく見ます。その結果の悲劇もよく見ます。 経営者の皆さんへ あなたの会社の社員はあなた程仕事へのモチベーションがありません。あなたが掲げる理念をあなた程信じてもいません。当然です。あなたと同じようにモチベーションがあり、あなたと同じように強烈な信念があれば、あなたと同じように起業するはずです。 もしあなたが仕事のモチベーションも信念もなく適当に会社を売り抜ければそれでいいなどと考えているならば、あなたのその価値の無い仕事は売り抜けることなど出来ないでしょう。 経営者の皆さんは起業した自分の理念に命を賭す価値があると信じていることでしょう。実際その価値は本物かもしれません。ですがあなたの会社の従業員は給料に見合っただけの労力を提供すればいいと思っています。そんなもんです。社員があなた
ssig33.com - ネイティブアプリ並のウェブアプリを云々
なんか最近そういうの流行ってるようですね。僕も考えを書いてアクセス数を稼ぎます。 ページ遷移を過度に抑えようとするな 下手に AJAX 使いまくるぐらいならページ遷移したほうがマシであることが多いです。世の中にはページ遷移を抑えようとして酷いことになってる JS を沢山見ます。よく考えろ。 ローカルストレージを活用しない localStorage に画像とか放りこむの異常に重くなるのでオススメしません。認証持たないサービスで設定値保存するのに使うとかに留めた方がよいと思う。 非同期な API 絶賛してて気に食わない感じはしますがこの記事を一読することをお勧めします。 localStorage は小さなデータをいくつか入れる分には十分に高速です。大きなデータを入れると十分に低速です。 scroll イベントに対してリスナーを置かない scroll イベントの監視は実際最悪のアイディアです。こ
高密度小池 ／ サン牧の本質的な問題
サン牧の本質的な問題 サン牧には問題がいくつかあって、表面的なことを言えば、 OpenSocial にちゃんと従っていないという点と、外部課金回りに重篤な不具合があるという二点です。 OpenSocial に従っていないという点は、 mixi がわがしっかりした作りになっているので、これはさほど問題になりませんが、外部課金のお粗末さはかなりのものと言えます。 ここでサン牧運営の Rekoo の技術力やモラルの問題を糾弾するのは簡単で面白いことですが、これもあまり本質的ではないと思います。 結論から言うと、本質的な問題は mixi が mixi アプリの提供を急ぎすぎたことであると僕は思っています。 mixi アプリは、資金を集めるために始められたサービスであると理解するのが、やはり正当かと思いますが、 mixi にマネーなり話題なりを集めるサービスを mixi アプリ上で展開して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
