タグ

エンジニアに関するbraitomのブックマーク (369)

  • 現場エンジニアが採用活動やってみたお話。

    BCU30での発表資料です

    現場エンジニアが採用活動やってみたお話。
    braitom
    braitom 2018/04/22
    現場エンジニアが採用活動をやって得られたことが書かれている。活動をすることで自分のキャリアについて再考できる、自分の会社のことが改めて分かるなど。
  • 数学分からず機械学習しても良いじゃん。だってエンジニアだもの。|石川 聡彦 @ai_aidemy

    こんにちは、石川(@Aidemy)です。はてなブログからnoteにちょっと浮気したつもりでしたが、noteのほうが書き心地が良いので今日もnoteです。 機械学習には数学の予習が必要なのか? さて、以下のツイートがそこそこファボられまして。『人工知能プログラミングのための数学がわかる』の著者としては黙っておれん!ということで、noteにまとめます。結論としては(数学の参考書を執筆しておきながらw)「数学の予習は不要だと思う派」ではあります。 勿論、数学が完全に不要と言っているのではなく、入り口として数学は不要だよね、という趣旨です。概ね同意のツイートも多く、こんな感想が寄せられました。 もちろん、機械学習エンジニアとして腕を磨いていくなら、線形代数や微分・確率統計などのテーマは押さえておくべきと感じます。特にTwitter機械学習界隈はプロ意識の高いが多いので、数学をしっかりやるべき、と

    数学分からず機械学習しても良いじゃん。だってエンジニアだもの。|石川 聡彦 @ai_aidemy
    braitom
    braitom 2018/04/22
    突き詰めたいなら学ばなきゃだし、道具として使いたいだけなら学ばなくてもいいんじゃない派。道具として使っていく中でもっと突き詰めたくなれば自然と勉強するだろうし。
  • 本当に良いエンジニアはいないのか?企業が採用に苦戦する本質とは - Grooves開発ブログ

    こんにちは。grooves にて Forkwell の事業責任者を務めている、赤川と申します。 この数ヶ月、 grooves では全事業部で積極的にエンジニアの採用活動を行ってきました。 当初は応募獲得に苦戦するだろうと思っていたのですが、結果は真逆で、あまりにも魅力的な方ばかりから応募いただけるので、採用に迷うことのほうが多いという結果になりました。 結果的に当初の予定より人員計画を増やすことになったのですが、それでもこの人と働きたいと思った方全員を採用できる状況ではなく、私たちとしてもぜひ一緒に働きたいと思っている方で、grooves を第一志望です、と言ってくれる方に対して採用枠の充足を理由にお断りしなければならないのは、非常に辛いことでした。 世の中には素晴らしいエンジニアがたくさんいるということを、改めて認識しています。 一方で、grooves が運営する Forkwell の元

    本当に良いエンジニアはいないのか?企業が採用に苦戦する本質とは - Grooves開発ブログ
    braitom
    braitom 2018/04/19
    良い。“エンジニア自身が、「こんな組織にしたい」を言語化し、それに向けてどんな取り組みをしているのか発信していく。それに共感した人が集まり、理想とする開発環境ができていく。”
  • 学生インターンを受け入れました - 下町柚子黄昏記 by @yuzutas0

    以下ブログ記事に対するアンサーエントリーです。 リクルートのインターンに参加しました | monolog稿は個人の見解であり、所属する組織を代表するものではありません。 うちのチームで先月までインターンをしていた @sukukyon から献が届いたw pic.twitter.com/80XqVaz9Em— ゆずたそ (@yuzutas0) 2018年4月4日 短い期間ではありましたが、インターン生である@sukukyonのメンターを務めました。 あまりメンターらしいことは出来なかった気もしますが、何とか無事に修了しました。 総論:最高のインターンだった 最高のインターンで最高にやっていきを発揮して最高の成果を出しました。 ということで、概ね上手くいきました。 成功要因としては「関係者全員がお互いをリスペクトできたから」だと思っています。 非常に良い関係性を築けていました。 まず何よ

    学生インターンを受け入れました - 下町柚子黄昏記 by @yuzutas0
    braitom
    braitom 2018/04/16
    すばらしい。チームとして会社としてインターンをちゃんとやっている。
  • 高速開発の戦略。石川洋資が献立アプリ『タベリー』で実行していること | キャリアハック(CAREER HACK)

    [プロフィール]石川 洋資 (@_ishkawa) | 10X inc. Co-Founder, CTO 面白法人カヤック、LINEでの複数の新規事業開発を経て、メルカリ/ソウゾウへ。 メルカリ/ソウゾウではプリンシパルエンジニアを務める。オープンソースプロジェクトへの参加や執筆活動も行っており、2017/2には「Swift実践入門」を出版。 「大学卒業後、カヤック、LINE、メルカリで新規事業の立ち上げを経験した後に、メルカリの同僚だった矢さんと会社をつくることに。モノをどのようにつくるかも重要だが、それ以前に何をつくるかが重要だと痛感していたところで、一緒に答えに辿り着けそうな人に誘ってもらえたのが起業を決意したきっかけ」 立ち上げ時はiOSアプリのUI検証に集中 プロダクトが人の役に立つものになるかどうかは、実際に人が使ってみるまでわからない。そんな状況を考慮して、「タベリー」開発

    高速開発の戦略。石川洋資が献立アプリ『タベリー』で実行していること | キャリアハック(CAREER HACK)
    braitom
    braitom 2018/03/29
    ふむ。“きれいなコードか、開発速度か。決して二元論ではありません。きれいなコードを書くことは、開発速度をだすための手段”
  • 今後のフロントエンドについて(仮)

    bonfire frontendで発表した今後のフロントエンドの話です。

    今後のフロントエンドについて(仮)
    braitom
    braitom 2018/03/29
    フロントエンドの話と言うよりエンジニアの心構えとか気持ちの話だった。とても良い。
  • #MANABIYA 2018 技術者としての成長のための技術トレンド

    M12_数百台の開発サーバをリフトアンドシフト! Azure Migrate 活用ポイント [Microsoft Japan Digital Days]

    #MANABIYA 2018 技術者としての成長のための技術トレンド
    braitom
    braitom 2018/03/29
    この考え大事だよなあ。どうせ今の仕事では使えないからと考えるの良くない。"仕事で必要なようにする"
  • 20代エンジニアの成長を阻む7つのパターン(まとめ記事) - Qiita

    10分で生産的なミーティングができるWebサービス「minmeeting」を開発している伊勢川です。 日は、これまで連載で紹介してきた2年目〜5年目エンジニアが陥りがちな症状と予防を要約して、まとめ記事を書きました。 網羅的にパターンを洗い出した訳ではなく、たまにそういうやつおるなという「おるおるネタ」の7選です。 若手エンジニアの皆さんは、ぜひこのようなくだらない失敗を繰り返すことなく、よりよい20代を過ごしていただければと思います。 Google依存症 Googleを調べれば何でもでてくる便利な時代が生んだ症状です。 症例 エラーログをGoogleで調べて出てこなかったら、それは解決方法がないと思ってしまう。 新しいことをやろうとして、Googleに実現方法が書いてなかったら実現不可能と思ってしまう。 予防法 Googleは日語が苦手なので英語で聞く。 Googleで見つからない解

    20代エンジニアの成長を阻む7つのパターン(まとめ記事) - Qiita
  • やっていく技術テーマを探す - はこべにっき ♨

    Webエンジニアを8年くらいやっていて、なんとなく、一通りのことはできるようになってきた。ただ、ちょっと得意な分野もあるとはいえ、基的になんでも屋さんとしてやっているので、技術者としてのアピールがいまいちだなーというのが気になっている。そこで、技術者としての自分をアピールできそうな技術テーマを一つ選んで、それにじっくり取り組んで見ようと考えた。 しかし、取り組む技術テーマをうまく選ぶ自信がない。そこで、ちょっと作戦を考えて取り組む技術テーマを見つけようと試行錯誤してみたので紹介してみる。 ステップ1: 指標を考える やっていく技術テーマを見つけるにあたって、テーマの候補をスコアリングしてみることにした。漠然とスコアをつけるのは難しいので、自分が普段技術テーマに取り組むかどうかを考えるときに気にしていることを思い出して、5つの指標に分解してみた。 指標1: 自分の興味 自分がおもしろい、や

    やっていく技術テーマを探す - はこべにっき ♨
    braitom
    braitom 2018/03/18
    取り組んでいく技術テーマの選び方について。指標を考えてスコアをつけて可視化する。よい。
  • paymoチームでもバグバッシュ大会を開催してみたらめちゃくちゃ良かった

    こんにちは。 Android/React-Nativeエンジニアの@kiriminです。 以前、Kyashブログで紹介されていた、B1グランプリという取り組みがとても素晴らしいなと思ったので、Kyashチームをリスペクトしているpaymoチームでも対抗して(?)バグバッシュ大会を開催してみました。 バグバッシュ大会とは基的にはKyashさんでのやり方を参考にしたのでそちらを見て頂ければと思います。 ざっくり説明すると、みんなで時間をとってアプリを触ってバグを探し、報告数を集計して表彰したり検出されたバグを皆でワイワイ眺めたりする会です。 やっていき方「やりたいね〜」だといつまでもやれないと思ったので、わりとエイヤでゴリ押ししました。 大会のようす多くの人の時間を長く確保するのは難しいので、開催時間は一旦30分にし、15分でバグを見つけ、15分で振り返るというスケジュールにしました。 初回

    paymoチームでもバグバッシュ大会を開催してみたらめちゃくちゃ良かった
    braitom
    braitom 2018/03/17
    面白そう。“みんなで時間をとってアプリを触ってバグを探し、報告数を集計して表彰したり検出されたバグを皆でワイワイ眺めたりする会です。”
  • TechBlog運用の難しさとHERPでの考えについて(TechHub公開に寄せて)

    HERPの技術発信の場として、HERP TechHubをリリースしました。会社のドメイン上ではなく、個人のブログのHubとしてのページを作成する形をとっています。 それに至った背景について書いてみたいと思います。 TechBlogのあり方を考えてみるTechBlogの目的と内包している問題について、エウレカでTechBlogの開設・運用をリードした経験から得られた課題も踏まえて考えてみる。 TechBlogの目的 従来のTechBlogの開設・運用の目的は以下の3つにまとめられると思う。 ブランディングを通じた採用力の向上エンジニアの個人ブランディングエンジニア全体・技術貢献ブランディングを通じた採用力の向上 エンジニア採用においては情報発信は欠かせない。もちろん一番大事なのは良いUXを提供できるプロダクトを作り、その品質を上げていくことだが、それだけでは社外の人間からして技術への考え方や

    TechBlog運用の難しさとHERPでの考えについて(TechHub公開に寄せて)
    braitom
    braitom 2018/03/15
    企業の技術ブログを個人ブログのハブとして作成した話。企業ブログの難しい点、どういう考えのもと個人ブログのハブにしようと思ったのかが書かれている。この方法いいな
  • エンジニアの文化とか採用についてやってきたこと - FLEXY(フレキシー)

    合同会社テンマドで代表社員をしています山岡です。基PHPやNode.jsのエンジニアですが、社外CTOや技術顧問など、アドバイザーとしていろいろな会社のお手伝いをしています。 情報の共有から始める アドバイザーとしてのご相談をいただく場合、そもそもまだ社内にエンジニアが数人しかいなかったりして、この先どうチームとして育てていけばいいのかわからない、その部分を手伝ってほしい、というケースが多いです。 その場合、どこから始めるかというと、情報の共有と見える化から始めることが多いです。esaなどMarkdown記法で気軽に書けるドキュメントツールを利用して、どんな些細なことでも書くようにしてもらいます。例えばサーバーでの作業計画とそのログ、フレームワークやライブラリの使い方など。 書くハードルをどうやって下げるかがポイントです。考え途中や調べ途中のものであっても、とりあえず書いて共有する癖を

    エンジニアの文化とか採用についてやってきたこと - FLEXY(フレキシー)
  • eureka, Inc. のエンジニアブログをMediumに移転致しました。

    皆さん、こんにちは。CTO室の責任者をしている梶原です。 eureka, Inc.で運用していたエンジニア・ブログを自社で運営しておりましたが、Mediumにリプレースしました。 同じような事を検討している方がいらっしゃれば参考になるかと思い、MediumにStoryを残させてもらいます。 解決したかった課題はなんだったのか以前はWordpressで実装しておりました。執筆者として、また管理者としての観点で、以下のような課題がありました。 執筆者としての課題執筆者が執筆開始までに実施すべきタスクが多く、執筆することの心理的なハードルが高い。執筆者にとって、Wordpressの入稿のインターフェイスは手軽ではなかった。イメージの縮小・拡大やスライドなど埋め込みで表示するには、HTMLをベタ書きなどがあった。(当然書くのは良いんだけど、面倒くさいって意識)ラベル、カスタマイズフィールドの入力方

    eureka, Inc. のエンジニアブログをMediumに移転致しました。
    braitom
    braitom 2018/03/10
    なるほど。個人の成果にも繋げることでモチベーションもあげるってことか。うまいなあ。“つまり、Mediumへのアウトプットをすることで、個人としてのアウトプットの蓄積になります。 ”
  • エンジニアもビジネス目線を持つべき理由 | ベイジの日報

    エンジニアはコーディング技術や実装力だけを磨けばいいわけではなく、デザイナーはビジュアル表現力だけを高めればいいわけではない。ビジネスにおいて求められるのは何であるかを考え、常に問題解決を行う意識で臨まなければならない。それはエンジニアもデザイナーも皆同じだろう。 現在、テスト公開後のフィードバック対応を進めているが、ふと気付くとリストに書かれたタスクをこなすだけの作業になってしまい、提案や問題解決の視点が抜けていた。 クライアントがその要望を発するのには、理由や背景が存在する。背景に何があるのか、何が求められるのか、要望を実現するためにはどう動くべきかという点に対し、プロとしてユーザー視点も忘れず、業務フローの組み立てまでも自分の責任範囲で行っていくべきだ。ただの修正作業にしてはいけないし、ディレクターの指示を待っているだけでもいけない。 これはそのまま社内やチームとしての取り組みにも当

    エンジニアもビジネス目線を持つべき理由 | ベイジの日報
    braitom
    braitom 2018/02/20
    同意。製品やサービスの開発だけでなくどんな活動でもこれを考えられないと破綻する。“正解のない問いへの回答や提案を行っていけるように研鑽を積んでいくことこそが大切だと感じる”
  • 「エンジニアの生き方」について、野球代表として話をしてきました(notセルフプロデュース) #devsumi2018 - Lean Baseball

    こんばんは野球エンジニアです. 「CTO」という肩書は僕の場合に限り「野球エンジニア」のエイリアスです.*1 この写真は,登壇準備直後見事にガララーガガラガラ*2だったB会場の様子です. なお,結局空席目立ちましたがすっごくいい気持ちでお話をさせてもらいました. ※写真はモブプロでおなじみの@TAKAKING22さんから提供いただきました,thx! DevSumi 2018運営の皆さまありがとうございます! 縁あって初めて登壇させて頂いたDevelopers Summit 2018の発表をちょっとふり返りつつ,「発表の補足・言えなかったこと」および、「はじめてのデブサミ」にフォーカスを当ててふり返りたいと思います. TL;DR 私の話は「セルフプロデュース」じゃなくて「生き方」の話でした(エンジニアとしての) 他人事(ひとごと)・余所事(よそごと)で盛り上がりすぎるのはやめよう,というのが

    「エンジニアの生き方」について、野球代表として話をしてきました(notセルフプロデュース) #devsumi2018 - Lean Baseball
    braitom
    braitom 2018/02/17
    ほんとこれ。"「ウチの会社じゃできない」「私じゃできない」とかいう,「チャレンジもしてないのに「できない」感覚に陥る」事が周りをみていておおいなあという印象があります"
  • シリコンバレーに辿り着いたソフトウェアエンジニアが直面したキャリアの分岐点と、その選択で大事にした指針たち - GeekOutコラム

    インターネットの上ではhmskと名乗っている者です。現在はアメリカはサンフランシスコにあるIndiegogoという会社で、同名のクラウドファンディングプラットフォームサービスに関するソフトウェア開発に従事しています。 Indiegogo: Crowdfund Innovations & Buy Unique Products 私が初めてアメリカを訪れたのは、2009年。大学4年生のときでした。その後、特に留学や出張の機会、海外志向があったわけでもなかったのですが、キャリアの分岐点で進む方角を何となく選んでいるうちに、今の場所に辿り着いていました。 サンフランシスコ、ひいてはシリコンバレーでのソフトウェア開発の仕事と聞くと、今ならとても高い給料や家賃が話題の中心になるかもしれません。初めて私が訪れた当時は、AppleGoogle、Dropbox、GitHubといった会社が集まるこのエリアは

    シリコンバレーに辿り着いたソフトウェアエンジニアが直面したキャリアの分岐点と、その選択で大事にした指針たち - GeekOutコラム
    braitom
    braitom 2018/02/10
    しんどい方を選んで、それを前向きに捉えられるってのはやっぱ大事だな。すごいと思う人はけっこうこの思考を持っている気がする。
  • ソフトウェアエンジニアが当たり前にやるべき事 - そーだいなるらくがき帳

    manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう? ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう? これは自戒をかなり含むが不満をSN

    ソフトウェアエンジニアが当たり前にやるべき事 - そーだいなるらくがき帳
    braitom
    braitom 2018/02/10
    ごもっともだ。かっこいい“ 我々はソフトウェアエンジニアだしOSSは公開されているので問題があるならパッチを送ればいいし、不満があるなら要望を出せば良い。 愚痴はTwitterに書いても作者に届かない”
  • エンジニアの次のステップへの勉強法 - Qiita

    言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的に成り立ってしまっているので、それ以上成長をする必要がないのです。 まあ、そういう生き方もありかな?って思うので、それでいいやって思う人は続きは読まなくてもいいかなって思います。 ここから先はエンジニアとして技術を伸ばすことが楽しい、ものを作ることが楽しい、

    エンジニアの次のステップへの勉強法 - Qiita
    braitom
    braitom 2018/02/04
    賛否両論ありそうな内容だけど機械学習の知識をあくまでもプラスアルファ要素として書いているのは良い。
  • キャリアチェンジしてフロントエンドエンジニアとして採用されるまでの記録。|Yuka Masuda

    勉強を始めた頃にこういう系の記事を色々と読んで参考にしたんだけど(これとかこれとか)、日語でもあるのか探してみたときにあまり具体的なのは見つからなかったので書いておきます。 ※ 以下は主な勉強内容をかなりシンプルにしてまとめたもので、実際にはよく迷走していたし、この他にも細々と色々勉強してました。使った教材は全部英語だけど、英語できなくても大体の流れ&期間を知る参考にはなるかと思います。 HTML/CSS & JS 超基礎(2月〜4月)仕事辞めるキャリアチェンジするプログラミング勉強する!と決めたのが2月。ブートキャンプに行くべきか自分で勉強するべきか、色々考えた末に自分で勉強することに。仕事を辞めるまで2ヶ月弱あったので、まずは勉強する習慣を作ろう、当にこれをやりたいと思えるのか試そうとしていたのがこの期間。 最初にCode SchoolのHTML/CSS, JavaScriptの有

    キャリアチェンジしてフロントエンドエンジニアとして採用されるまでの記録。|Yuka Masuda
    braitom
    braitom 2018/02/04
    これはすごい。かっこいい。意志を持って行動できる人は強い
  • 【k8s合宿】 Kubernetesのログ分析環境を作る - Uzabase for Engineers

    こんにちは、SPEEDAのSREチームでエンジニアをしている阿南です。SPEEDAのSREチームでは、昨年末kubernetesについて理解を深めるために合宿を行いました。やり方はA〜Cの3チームに分けて、それぞれのチームでkubernetesに関することを調査、構築するという形式で、今回はAチームが実際にやってみた内容についてブログを書きたいと思います。(それぞれのチームでかなりボリュームがあるので、複数回に渡って連載的な形でお届けしたいと思います。) Aチームでは、kubernetes番環境に投入するにあたり、ログ収集周りをあまり調査できてないなと感じ、GCP上に環境を作ってみることにしました。 構築する環境 構築手順 クラスター構築 wordpress + MySQL構築 Fluentdイメージの作成 ConfigMap設定 DaemonSet設定 まとめ お知らせ 構築する環境

    【k8s合宿】 Kubernetesのログ分析環境を作る - Uzabase for Engineers
    braitom
    braitom 2018/02/01
    内容よりも1つの技術を合宿でチームごとに調査、構築するというやり方が目についてしまった。このやり方すごくいいなー