タグ

2016年8月16日のブックマーク (17件)

  • 初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG

    こんにちは、fluct SSP開発部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名(評価者)に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。(言うまでもなく、私は被評価者です) ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明

    初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG
    ozw-sei
    ozw-sei 2016/08/16
    やってみたい
  • 気力がない人は例外なく「体力」が足りない

    コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能(広告ブロック機能を持つ拡張機能等)を無効にしてページを再読み込みしてください。 ✕

    気力がない人は例外なく「体力」が足りない
  • 2年半のリモートワークを振り返ってみる - じまろぐ

    フルリモートワークな会社に勤めて2年半が経った。簡単に振り返ってみる。 前職と現職 前職はごく普通の勤務体系(10:00 ~ 19:00)で働いていた。 今いる会社は全社員がフルリモートワークで、出社義務も一切なく、勤務時間も各自の裁量で決められる。業務はフロントエンドの受託開発をメインとしていて、CodeGridという自社の技術系メディアの運営もしてる。担当業務としては案件のフロント部分全般と、記事執筆がある。 コアタイムとかそういった規則が一切ないので、いつどこで働くかを自分でコントロールできる。そんな会社に入って2年半が経過したので振り返ってみる。 適応しようともがく期 いきなりフルリモートに適応できる人は稀だと思う。業務のことも同僚のこともわからないので、最初はとにかく環境に適応するために邁進。心理的な余裕が少なく、ゲームやっててもあんまり楽しめてなかった気がする。 リモートワーク

    2年半のリモートワークを振り返ってみる - じまろぐ
  • Change the base branch of a Pull Request

    ProductChange the base branch of a Pull RequestYou can now change the base branch of an open pull request. After you’ve created a pull request, you can modify the base branch so that the changes in the… You can now change the base branch of an open pull request. After you’ve created a pull request, you can modify the base branch so that the changes in the pull request are compared against a differ

    Change the base branch of a Pull Request
    ozw-sei
    ozw-sei 2016/08/16
  • Rails5 が示したサービス開発の新しい指針についての考察。 - ボクココ

    ども、@kimihom です。 Rails5.0 の正式版がついにリリースされた。 Riding Rails: Rails 5.0: Action Cable, API mode, and so much more Rails 5といえば、 ActionCable での WebSocket によるサーバープッシュのリアルタイム処理が注目されがちだが、個人的には今後のシステムの開発指針を Rails が示した重要なリリースになっていると感じている。その原動力となっているのが、 あの "Turbolinks" だ。 マルチプラットフォーム開発に対する提案 ではどんな話かっていうと、まず Rails としては JavaScript で複雑なロジックをたくさん書いたり状態を管理するような処理を書かないことを選んでいる。以下の動画は今後の Rails において非常に重要な意味を持っている。 Rail

    Rails5 が示したサービス開発の新しい指針についての考察。 - ボクココ
    ozw-sei
    ozw-sei 2016/08/16
    we are not google, we are not facebook
  • Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!!

    2017/7/27に開催されたセプテーニ・オリジナル / オプト / CyberZ合同イベント「Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!!」の発表資料です。 イベントページ: http://scala-scrum-ddd-gatlingtalk.connpass.com/event/34172/Read less

    Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!!
  • マイクロサービスとDDDをGo言語とScala+Akkaで比較したらEventSourcingの話にもなって面白かったまとめ - yoskhdia’s diary

    Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。(結構、色々な話題に飛んでいるので難度高い。) まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術(どんな言語使うとか、どんなアーキテクチャにするとか)の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ(一部抜粋) Slackからの引用のためテキストベースです。 事の始まりは、荒木さん(以下、 @applideveloper )の発言でした。 (この記事絡みですね。 集合知で各

    マイクロサービスとDDDをGo言語とScala+Akkaで比較したらEventSourcingの話にもなって面白かったまとめ - yoskhdia’s diary
  • Slick3用のブロッキングAPIを作ってみました - たけぞう瀕死ブログ

    github.com なぜ作ったのか? 事の発端はSlickのこのイシューです。 github.com GitBucketはServletベースということもあり、Slick3のDBIOは非同期実行のメリットが得られないのに複雑さだけが劇的に向上してしまうこと、プラグイン開発者にもモナディックなプログラミングを強いてしまうことなどから当面Slick3へのバージョンアップは行わず、Slick2に留まることにしていました。 しかし、Slickは場合によっては以下のような酷いSQLを生成することがあります。Slick3にはクエリコンパイラが改善されている(今後の改善も期待できる)という利点があるため、可能であるならバージョンアップしたいというのが正直なところでした。 github.com そこで冒頭のようなイシューが上がっていたため、これはコントリビュートのチャンス、もしSlick3でSlick2

    Slick3用のブロッキングAPIを作ってみました - たけぞう瀕死ブログ
    ozw-sei
    ozw-sei 2016/08/16
    Blocking Slick
  • 暗号化と圧縮、どちらを先にするべきか? | POSTD

    こんなことを想像してみてください。 あなたは大企業で働いています。仕事はかなり退屈です。端的に言えば、あなたの顔も見たくないという経理担当の3人しか使わないようなアプリケーションのために定型的なコードを書いて、才能を無駄にしているという状況です。 あなたが当に情熱を注げるのはセキュリティです。毎日、 r/netsec を読み、仕事の後にはバグ報奨金プログラムに参加しています。ここ3カ月間は手の込んだ株式取引ゲームをプレイし、報奨金を得ています。ヒープベースのバッファオーバーフローを発見し、優良株を選ぶ手助けとなるAVRシェルコードをいくつか書いたからです。 あなたが取り組んできたビデオゲームが、実は巧妙な偽装のリクルートツールであったと判明し、全てが変わります。世界最高のセキュリティコンサルタント会社、Mont Piperが人材を募集していて、あなたは面接に行くことになったのです! 飛行

    暗号化と圧縮、どちらを先にするべきか? | POSTD
  • JavaScript の難しさとは何か - mizchi's blog

    JSの学習コスト高いかという問題、言語のコア自体はシンプルだが細かい == とかのハマりどころが多いのと、言語機能自体がシンプルすぎてエコシステムを理解してモジュールを扱うところに辿り着くのが大変、という問題に分類できる— 現場の声 (@mizchi) 2016年8月15日 jQueryの学習コストは、DOMはツリーなんだよという概念の獲得と DOM API の抽象サブセットを覚えるというだけで、2016年現在は jQueryによるUI設計論(ここが高まるとBackboneとかその辺)みたいなものに手を出す必要がないなら、そんなでもないんだろうな— 現場の声 (@mizchi) 2016年8月15日 Reactが難しいと言われる場合、仮想DOMという概念がやや難しい、というか非常にCS的なアルゴリズムとデータ構造が背景にあって、その上で単純なトップレベルAPIとアルゴリズムを理解してないと

    JavaScript の難しさとは何か - mizchi's blog
  • ハイパフォーマンスDjango - Model - Qiita

    High Perfomance Djangoを読んでとても勉強になったので、備忘録メモ。 クエリの数を減らせ select_related prefetch_ralated これをちゃんと使ってね。 開発中は、Django Debug Toolbarで発行クエリを確認。 クエリの実行時間を短く indexをきちんと張る でかいJoinは避ける でかいテーブルにはall()はやめて、LIMITかける 存在チェックはspam.count() > 0じゃなくて、spam.exists()で Foreign Keys Generic Foreign Keysは便利だけど、裏でパフォーマンス悪いクエリ投げてることある。 自分で外部キー張った方がいい場合も。 cached_propety 実行コストがかかる & 何度も呼ばれるプロパティに対しては、キャッシュが有効。 https://docs.djan

    ハイパフォーマンスDjango - Model - Qiita
  • DockerとMakeを利用したRPMパッケージのビルド環境 | メルカリエンジニアリング

    SREチームの@cubicdaiyaです。今回はDockerとMakeを利用したメルカリの自作RPMパッケージのビルド環境について紹介します。 メルカリの自作RPMパッケージ事情とVagrant、そしてDocker メルカリの開発およびプロダクション環境では現在CentOS6と7を利用しており、随時CentOS7へ移行中です。そのため、自作RPMパッケージをビルドする際はCentOS6と7向けにそれぞれビルドしています。ビルドしたパッケージはyumリポジトリサーバにアップロードした後、必要に応じてyumでインストール、Ansibleのplaybook化を行います。 RPMパッケージの作成はSREチームのメンバーが行っており、各自のローカルマシン上において make {パッケージ名} を実行するだけでCentOS6と7向けのRPMパッケージをビルドできる環境をDockerで構築しています。

    DockerとMakeを利用したRPMパッケージのビルド環境 | メルカリエンジニアリング
  • 「なぜDI(依存性注入)が必要なのか?」についてGoogleが解説しているページを翻訳した  - Qiita

    イマイチ理解しきれていなかったDIに関して調べていところ、Google Guiceの解説がすごく分かりやすかったので、和訳してみました。 (ところどころ意訳気味です。明らかに解釈の誤った訳がありましたら、ご指摘ください) ちなみにGoogle Guiceというのは、Googleが開発したDIライブラリです。この例ではJavaが使用されていますが、Scalaでも使用可能です。最近Play Frameworkでも採用されたので話題になっているようです。 用語の定義 文を読む前に目を通すことで、内容をスムーズに理解できます。 用語 意味 文中の例

    「なぜDI(依存性注入)が必要なのか?」についてGoogleが解説しているページを翻訳した  - Qiita
    ozw-sei
    ozw-sei 2016/08/16
  • ニフティ・はてな・GREEを経て、伊藤直也が見据える「エンジニアのキャリア」とは? | キャリアハック(CAREER HACK)

    「ニフティ」「はてな」「GREE」を経て、最近フリーのプログラマとして新たなキャリアをスタートさせた伊藤直也さん。スタートアップと大手企業の両方を経験した伊藤さんが考える「理想のキャリア」とは? エンジニアの理想のキャリアとは? WEB・IT業界は、できてまだ数十年の若い業界である。第一人者たちが未だ現役ということも少なくはなく、それゆえ業界における理想的なキャリアというものが確立されているわけでは決してない。エンジニア一人ひとりが試行錯誤しつつ、自らのキャリアを模索していかなければならないのが現状だ。だからこそ、見識ある先達たちが自分のキャリアをどのように考え、どういったキャリアを選んでいるのか知ることが重要なのではないだろうか? そこで今回は、スタートアップと大手企業の両方を経験した伊藤直也さんに、エンジニアにとって理想のキャリアとは何なのか、考えを伺った。 エンジニアが、企業に属する

    ニフティ・はてな・GREEを経て、伊藤直也が見据える「エンジニアのキャリア」とは? | キャリアハック(CAREER HACK)
    ozw-sei
    ozw-sei 2016/08/16
    やっぱり仕事って、締め切りのあるタスクを自分に持ってきてくれる人とか、そういう他者との関係性があって初めて成り立つものだと思います。人間、自分で自分を律することは、思っている以上に難しい
  • React でも Bootstrap のコンポーネントを使う - present

    React で SPA を実装する場合も、 デザインは Bootstrap のお世話になりたい。 クラスを指定するだけで使えるコンポーネントは普通に使えそうだけど、 Tooltip や Dropdown や Modal のような、 jQuery に依存したコンポーネントは React でそのまま使えないのが残念。 そこで Bootstrap のコンポーネントを React コンポーネントとして実装した、 React-Bootstrap を試してみた。 github.com JavaScript の部分を jQuery から React に実装し直したシロモノなので、 別途 BootstrapCSS は必要。 Bootstrap を使って自分がよくやるレイアウトを React-Bootstrap で再現してみた。 var React = require("react"); var Re

    React でも Bootstrap のコンポーネントを使う - present
  • 「iPhone」「過去の失敗」「Appleの未来」についてAppleのティム・クックCEOが答える - GIGAZINE

    Appleのティム・クックCEOが、The Washington Postのロングインタビューで、AppleCEOとしてありたい姿や今後のスマートフォン市場、iPhone頼みの現状、過去の大失敗やAppleの次なる一手などについて答えています。 Tim Cook, the interview: Running Apple 'is sort of a lonely job' | The Washington Post http://www.washingtonpost.com/sf/business/wp/2016/08/13/2016/08/13/tim-cook-the-interview-running-apple-is-sort-of-a-lonely-job/ Q: あなたはかつて「よくいる伝統的な最高経営責任者(CEO)にはなりたくない」と言いました。これは何を意味するのですか

    「iPhone」「過去の失敗」「Appleの未来」についてAppleのティム・クックCEOが答える - GIGAZINE
  • long_time_work_cannot_finish_tasks

    先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい? 困ったことはない?」と尋ねられ、 僕は即座に「すごく楽しいですよ。日で働いていた会社とは大違いです」と答えた。 「日では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか?」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる

    long_time_work_cannot_finish_tasks
    ozw-sei
    ozw-sei 2016/08/16