2年目の技術系編集者が勝手に日本の編集者を代表して、若手エンジニアのみなさんに伝えたいこと/wakate-funwari-study_codezine.editor
twitterでなんどもつぶやいてるので多分知られているとは思うんですが、Web配信の技術という本を書きました。 せっかくなんで、なんでまたこんな本を書いたのかとかどういう流れだったのかみたいなのを簡単に書いてみようかなと そもそもどういう本なのか 非常にタイトルを決めるのが難しい本でした。 サブタイトルに「HTTPキャッシュ・リバースプロキシ・CDNを活用する」とあるようにいわゆるHTTPキャッシュの本なわけですが、コンテンツ配信の技術といえばCDNの印象が強く出ますし（本書はCDNの使いかたというわけではないです）、Web配信といえば動画ストリーム配信（VTuberの配信とか）を思い浮かべる人も多いと思います。 今考えればWebコンテンツ配信の技術とすればよかったかもと思いつつ、今度は長くなりすぎるのでなかなか難しいです。 ということでHTTPキャッシュを使ってWebサイトを高速化した
昨年7月末に4年半ほど勤めたDMMを退職しました。 その後はずっと長い夏休みを満喫してたんだけど、元同僚にあやしい取材をされて、記事が出るから宣伝のために退職ブログを書け、とか言われたのですよ。 結局取材記事↓の公開には全然間に合わなかったんだけど、記念に書いたのを公開しときます。 - 「大いにやらかし、飽きたら逃げよ」ー元DMM・個性派おっさんエンジニア 佐々木健のITジョブホッパー道 それと、そろそろちゃんと働かなきゃなあ、とも思うので、何をやってたのか等を含めてまとめておくのも大事よね。 そして、以下に書くことはあくまで個人の感想です。 人によっては同じできごとでも捉え方が全然違ったりするはずなので、書いてあることは全部信じることはせずに、取捨選択をしつつ、裏取りしつつ、用法・用量を守ってお使いください。 なぜDMMに入社したのか？DMMに入社する前は、24時間365日システムを監
権力格差が大きい国の文化圏では、権威勾配が大きくなります。また、個人主義であるほど自己主張がしやすくなるため、意見が生まれやすくなります。男性主義的であると、女性から男性への意見をしづらいと感じる社会であることを意味しています。また、不確実性忌避の傾向が高い国では新しいことや常識の外にあることを受容する力が弱くなり権威勾配が大きくなる傾向があります。 文化的権力格差 Q. あなたの職場では職位を尊称として使うか？たとえば、「〜〜部長」「〜〜課長」など。年少の同僚を「〜〜くん」や呼び捨てするなどの傾向はあるか？ Q. あなたの職場では上長の発言に疑義があっても明確な理由がなければ、反論すべきでないという風土があるか？ Q. あなたの職場では年齢が若い人は年齢が上の人の意見に反論すべきでないという風土があるか？ 年齢や権威に対してものが言えなくなる文化が強い場合、実際の職位の乖離を大きな権威勾
元コーヒー屋さんです。皆さんにコーヒー沼にハマってほしいため、美味しい（と思う）コーヒーの淹れ方を記します。 ▼コーヒーの淹れ方 ハンドドリップ、サイフォン、エアロプレス、フレンチプレスエスプレッソマシン、水出しとありますが、今回はハンドドリップです。ハンドドリップとはコーヒー粉をフィルターに入れ、上からお湯を注ぐことで抽出する手法です。フィルターにはペーパー（紙）、ネル（布）、金属がありますが、まずはペーパーがおすすめです。 ペーパー：油分が紙に吸収されてしまうが、お手軽。 ネル：油分が多く抽出されるが、お湯の淹れ方やネルの保存方法が面倒。 金属：多分美味しく淹れられると思うけど、使ったことがないのでわかりません。 ▼必要器具 グラインダー：必須。まずは手挽きのものでOK。コーヒー豆は粉にした瞬間から酸化劣化が始まるため、豆での保存がマスト。おすすめはカリタのナイスカットミルだけど高いで
名門校出身者たちを目の当たりにして 教育と格差の問題といえば、しばしば話題にのぼるのが東大生の親の年収である。2014年の調査によれば、東大生の育った家庭の半数強が、年収950万円以上の比較的裕福な家庭だという。 ここで問題視されているのは、階級の固定化である。つまり、裕福な家庭は多額の教育費を支払うことができるので、子供は高学歴化する傾向にある。学歴と収入は比例することが多い。結果的に、金持ちの家系はいつまでも金持ちだし、逆に貧乏人はいつまでも貧乏から抜け出せない――という問題だ。 だが、こうした問題提起に出くわすたび、いつも「ある視点」が欠けていると私は感じる。それは都市と地方の格差、地域格差である。 田舎者は、田舎に住んでいるというだけで、想像以上のハンディを背負わされている。 あらかじめ、どんな地域で育ったどんな人物がこの記事を書いているのか、簡単に紹介しておこう。 私は高校時代ま
Hacker Tackle 2018 発表資料
TL; DR どれだけ努力しても"ネイティブ並"は無理なので諦めが肝心 エンジニアは英語ができなくても話を聞いてもらえるので「伝える意思」と「分かったか分かってないかを絶対に曖昧にしない」こと 謝辞 このエントリは弊Android Projectのビルド待ち時間を使って書かれています。Android Studioさんに感謝します。 ビルド待ち時間にブログを書かれたくない場合は弊社は僕に全部盛りiMacを買ってください。 前口上 英語力に関するエントリは盛り上がりやすく荒れやすい気がするんだけど、それはやっぱりみんな英語は出来たほうがいいに決まってるしさりとて英語を身につけるのは難しいよねってことが分かってるからだと思う。 僕はエンジニアの中では比較的英語が得意な部類に入ると思うけど、それでも全然充分だとは思わない。ただ、これでやっていけないか？というと全然そんなことはないので、一番重要なの
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon Aurora Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適
先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回
東京スタジオのエンジニアの小山です。 この記事では、5月中に行われたサーバーサイド勉強会の内容を紹介したいと思います。 サーバーサイド勉強会の紹介や4月分の内容は前回の記事を見てください。 https://developer.aiming-inc.com/study/server_side_study_201704/ 5/11 LT 月初のLTです。 OSS Contribution ラスタム秘伝の LT スライド大作戦 https://rastamhadi.github.io/slides/lt_slides_server/ (sを押すとスピーカーノートが表示されます) 仮想電子工作のすすめ https://www.slideshare.net/ckazu/ss-77687982 #slack-trend 開発記 記号でRuby 快適なオフィスの室温を巡る細やかな試論 今回は全体的に真面
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
お知らせ：Qiitaにプログラマ向けの英語記事を書きました Qiitaに「和英辞典・自動翻訳だけじゃダメ！もっといい英語名を見つけるためのTips集」という記事を書きました。 この記事はその名の通り、クラスやメソッドの英語名を付ける際に、和英辞典や自動翻訳以外に検討すべき選択肢を説明したものです。 シソーラスを使う方法や、画像検索で自分のイメージと比較する方法など、僕が実際によくやっているテクニックを紹介しています。 また、普段はRubyプログラマ向けの記事をよく書いていますが、この記事の内容はRubyに限らず、いろんなプログラミング言語で汎用的に使える内容になっているはずです。 ちなみに、この記事を書いた背景は、社内で同じような話をよく繰り返しているからです。 この記事は「伊藤さーん！英語の命名手伝って－！」と社内で頻繁で聞かれるので、そのときに毎回答えている内容が元ネタになっております
FiNCではマイクロサービスでの開発をすすめており、バックエンドサービスの数は20を超えています。 今回はFiNCの数あるマイクロサービスのうち、FiNCアプリ内の「ランキング機能」のサービスを作った時の設計思想や実装について書きたいと思います。マイクロサービス化の一ケースとして、参考になる点があれば幸いです。 SummaryアプリケーションはRuby on Rails, データストアにMySQLとRedis (ElastiCache) を利用しています。記事中では以下のような点に言及します。 サービス設計 … サービスに持たせる責務、サービスの切り分け方データの同期(サービス間のイベント連携)の方法Redisを使ったランキングの実装RedisとMySQLを併用する設計と実装ビジネス要件今回、ビジネスサイドから話があったのは以下の二つでした。 歩数を用いたランキングをやりたい。 (短期目標
I've had a few conversations recently where I say things like, "the Japanese Ruby community uses Ruby for different things than in America"... and I get blank stares. Specifically, I mention that America is very centered on Rails and web apps with Ruby. No surprise, right? "But then," people ask, "if they're not using Ruby for Rails, what do they do with it?" And why does anybody care? For the sam
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
