大きな声では言えない無線LANエンジニアの本音
「無線LANにあまり大きな期待をしないでほしい」――。無線LAN関連の取材をすると、ネットワーク担当者や構築を支援したエンジニアの、こんな声をよく耳にする。 無線LANは家庭ではもちろん、駅やコンビニエンスストアでも無料で利用できるようになっている。比較的新しい無線LANアクセスポイント製品には、1Gビット/秒を超える通信速度をうたうものも登場している。今や「どこでも高速に通信が可能な技術」、というイメージが定着しつつある（写真）。 しかし、そのネットワークを構築・運用する“裏方”であるエンジニアは、思った以上に苦労しているようだ。とりわけ企業の中で使う無線LANは、スペース当たりのアクセスポイントの数が多く、快適な通信環境作りが難しい。冒頭の発言は、有線と同様の高速通信を期待する利用者への、いわば嘆きだ。 こうしたふと漏れた一言には、無線LANを活用するうえでのヒントが隠されている。技術
GitHub - isucon/isucon5-final
The MIT License (MIT) Copyright (c) 2015 tagomoris, kamipo, najeira, hkurokawa, making, xerial, hokaccha Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, a
理想的なエンジニアでありたい - kurainの壺
前回のエントリにかなり反響があって、友人達が数ブクマして終わりという想定もしていたので、少々驚いている。 エクスキューズを全く入れなかったのもあって、いろんな感想を持たれた。 フワッとした文章で論点もはっきりしてないので、 941 さんのブコメはもっともだと思う。 ただ、一番言いたかったことは、 "プライベートを犠牲にしなきゃ、理想的なエンジニアになれない" って発想が嫌だってことだ。 結構ブコメで"好きだからやっているんだ"っていうコメントが多くて、そんなのは僕も知っている。 僕もコーディング大好きで、なんの制約もなければ体力の続く限りやることもあるだろう。 自分の時間の内であれば、コードを書くのも勉強するのも犠牲なんて思わない。 でも、それでいいの? 持続可能なの?って話なんだ。 独身のひとは、好きなようにすればよいかと思う。その人だけの人生だし。 でも、テレビゲームしたり、漫画読んで
ISUCON5の本選に参加して惨敗しました - 平常運転
タイトルの通りです。 先日行われた、Iikanjini Speed Up Contestの略であるところのISUCON5の本選にはてなの若手エンジニア3人によるチーム「はむちゃん」で参加し、見事惨敗してきました。最後のスコア計測時に再起動試験をクリアできなかったので最終スコアはなしで、終了直前のベンチマークで出した値は4万点台だったので仮に再起動試験で同程度のスコアを出せていたとしても9位ライン、ということになります。isucon.net 予選が好成績で調子に乗っていた記事はこちらです。astj.hatenablog.com 本選の感想 最初に、今回の終了直後のこのツイートをもって感想とさせてください。 そらきれい— Julius/HP (@ast_j) 2015, 10月 31 ふりかえり 本選のお題が何になるかはいろいろ噂されていましたが、冗談半分に言われていたマイクロサービスとDoc
サーバーレスアーキテクチャという技術分野についての簡単な調査 - Qiita
BaaSの制約で実現しにくい要件があったときに、サーバーレスアーキテクチャという選択肢は魅力的に見えてくる。そこで今回は最も柔軟性が高いサーバーレスインフラストラクチャだと思われるAWS Lambdaを取り上げ、BaaSの代わりになりうるか検討する。 AWS LambdaのファンクションはJava 8で書ける。ということはGroovyでも書ける。ドメインクラスをJava/Groovyで書いてLambdaファンクションのなかで利用することができれば、サーバーレスアーキテクチャでも本格的なアプリケーションを開発できそうだ。 今後のアプリケーションインフラストラクチャ選択において、従来型のアプリケーションサーバーと、近年普及してきたBaaSに加え、サーバーレスインフラストラクチャという選択肢も増えるとすれば有意義だ。 非常駐型のデメリット 歴史的にはCGI/PHPのようなイベント駆動型のアプリケ
ISUCON5 で優勝しました - 酒日記 はてな支店
ISUCON5、予選を無事通過して10/31(土)に開催された本選に参加し、優勝しました。 チームは ISUCON 1 の時の初代「fujiwara組」再結成ということで、@songmu, @sugyan とのカヤックの元同僚メンバーです。 最初に、毎回素晴らしいイベントを開催、運営していただいている @941 さんをはじめとした運営チームの皆様、出題の @tagomoris さん、@kamipo さん、他すべての協力いただいた皆様に感謝を申し上げます。本当にありがとうございました！ 競技開始からベンチ実行まで 作った #isucon pic.twitter.com/5RZkPUsaPu— fujiwara (@fujiwara) 2015, 10月 31 ロゴがなかったので作った。 競技開始、まずは3台で相互にsshできるようにするのに一瞬戸惑う。port 22は開いていて、会場からは接
株式会社nanapiの取締役及びCTOを退任いたしました - UNIX的なアレ
jp.techcrunch.com 2015年11月1日をもって株式会社nanapiを含む３社が合併し、Supership株式会社となりました。 それに伴い取締役及びCTOとしての立場を退任いたしました。株式会社nanapi（始めた当初は株式会社ロケットスタート）では、６年半ほどCTOという立場で仕事をしてきました。一人で開発していたころから現在に至るまで、本当に様々なフェーズを経てきたなぁと思います。 これからはSupership株式会社において改めてサービス開発という現場にたちもどって、サービス開発の現場で戦っていこうと思います。 立場は変われど、会社の目指す先はより大きくなっているのでより現場にちかい立場で引き続き頑張っていくつもりです。 Supership株式会社でもエンジニアは引き続き募集しておりますのでぜひよろしくお願いいたします！ 新卒採用サイト｜Supership株式会社
Quipper のエンジニア採用プロセス コードテスト編 - @kyanny's blog
Quipper ではエンジニアを採用するにあたり、候補者に複数回の面接と、コードテストのための課題提出をお願いしている。 今年の春から夏にかけて、前任者から日本オフィスのエンジニア採用に関わる仕事を引き継いだとき、採用プロセスを変更した。それまでは一部の採用担当者だけが面談と合否判断をしていたが、エンジニア採用の場合は原則としてエンジニア全員が面談に参加可能とし、課題のレビューも全員が行うようにした（カレンダーに面談の予定を作るとき全員招待する。辞退しても構わない）そして合否判断の議論も原則としてエンジニア全員で行うようにした。 これによってブラックボックスだった採用プロセスを透明化できたが、課題のフィードバックを共有するとき、先に発言した人の意見に影響されてしまってフェアな判断が下せなくなる懸念があった。そこで、以下のようなやり方でフィードバックを共有することにした。 フィードバック記入
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
Quipper に入社してました | Born Too Late
2018/06/09 追記: 現在Quipper は積極採用中です。詳しくはコーポレートサイトかキャリアトレックをご覧ください。 ちょうど 2 ヶ月前に退職についてについて書いていたけど、その翌週の 9 月 7 日から Quipper で働いていた。 初出社 & 初プルリ済みです pic.twitter.com/PvmeYlgKpb — Yuya Takeyama (@yuya_takeyama) 2015, 9月 7 入社当日に Twitter に書いたりしていて、全然隠していたわけではないのだけど、さすがに入って直後だと「転職したぜイエーイ！」で終わる個人の日記レベルのことしか書けないだろう、ということでしばらく放置していた。 いまは入社から 2 ヶ月ほど経ち、日々の仕事や社内の雰囲気にも慣れてきたので、そういうところも紹介も添えて「転職してたぜイエーイ！」的な個人の日記を書いておこう
ISUCON5 で準優勝してきた #isucon
予選に引き続き、チーム白金動物園として rosylilly, mirakui と ISUCON 5 の決勝に参加した。 なんと 2 位を獲得した。やったぜ! いや fujiwara 組に負けたのは悔しいけど。 分担は予選とあんま変わってなくて、mirakui がインフラ・分析、rosylilly が実装 (あと博打)、わたしが実装とインフラを良い感じにやっていた。 やったこと 白金動物園の解答コードは予選含めて shirokanezoo/isucon5 に push したのでそれを見つつ、最終的に何が変化したかの話を書く。細かい試行錯誤とか、時系列での話は最後に「タイムライン」としてまとめてのせておきました。 利用言語は主に Ruby。補助的に Go で書いたフォワードプロキシサーバーを入れた。 diff 見る限り +2102 -54 lines なんだってさ。 app.rb に対しては
ISUCON5本戦にてスコアトップの18万点でfailしました - Qiita
チーム.datとして、インフラ担当の@kannyと実装およびファシリテーション担当の@TakatoshiMaedaの若手連合で参加しました。 負けた内容が内容なので悔しくて悔しくて悔しいです。優勝スコアが15万だったので本当に悔しいです。 スコアはダントツ一位やったんや…スコアは… #isucon pic.twitter.com/3dKxOYA7vq — 松本 勇気 (@y_matsuwitter) October 31, 2015 当日やったことを淡々と書いてみます。 今回の本戦については特段変わったことをしていないつもりですし、各チームがやっていて.datがやっていない施策も結構あった気がしています。 ISUCON5本戦課題について 時代はMicroserviceということで、雑に作られた複数のMicroserviceと連携するダッシュボードを最適化するという課題でした。 およそ下記の
ISUCON5 で準優勝しました - 鳩舎
今年も @mirakui と @sora_h と一緒に ISUCON5 に出場して、準優勝しました。 やったこと 時間は投入した時間。 12:00 : API リクエストを送る先の services が DB に入ってるけど大した数でもない(7つ)ので、全部アプリケーションにハードコードした。 これはのちにリクエストにプロキシを挟む時にコード変更だけでよくなったので地味に効いた。なお、これによる高速化はあんまりしなかった(そりゃそうだ)。 13:16 : API リクエストへのパラメータを保存している subscriptions の保管先を DB から Redis へ変更。 DB 問い合わせへの高速化というより、 JSON 形式から MessagePack 形式での保存になったことの方が重要な気がしてる ま、これも大した効果は出てない。 initialize でバグったら話にならないから、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
