BCU30での発表資料です
こんにちは、石川(@Aidemy)です。はてなブログからnoteにちょっと浮気したつもりでしたが、noteのほうが書き心地が良いので今日もnoteです。 機械学習には数学の予習が必要なのか? さて、以下のツイートがそこそこファボられまして。『人工知能プログラミングのための数学がわかる本』の著者としては黙っておれん!ということで、noteにまとめます。結論としては(数学の参考書を執筆しておきながらw)「数学の予習は不要だと思う派」ではあります。 勿論、数学が完全に不要と言っているのではなく、入り口として数学は不要だよね、という趣旨です。概ね同意のツイートも多く、こんな感想が寄せられました。 もちろん、機械学習エンジニアとして腕を磨いていくなら、線形代数や微分・確率統計などのテーマは押さえておくべきと感じます。特にTwitter機械学習界隈はプロ意識の高いが多いので、数学をしっかりやるべき、と
こんにちは。grooves にて Forkwell の事業責任者を務めている、赤川と申します。 この数ヶ月、 grooves では全事業部で積極的にエンジニアの採用活動を行ってきました。 当初は応募獲得に苦戦するだろうと思っていたのですが、結果は真逆で、あまりにも魅力的な方ばかりから応募いただけるので、採用に迷うことのほうが多いという結果になりました。 結果的に当初の予定より人員計画を増やすことになったのですが、それでもこの人と働きたいと思った方全員を採用できる状況ではなく、私たちとしてもぜひ一緒に働きたいと思っている方で、grooves を第一志望です、と言ってくれる方に対して採用枠の充足を理由にお断りしなければならないのは、非常に辛いことでした。 世の中には素晴らしいエンジニアがたくさんいるということを、改めて認識しています。 一方で、grooves が運営する Forkwell の元
以下ブログ記事に対するアンサーエントリーです。 リクルートのインターンに参加しました | monolog ※本稿は個人の見解であり、所属する組織を代表するものではありません。 うちのチームで先月までインターンをしていた @sukukyon から献本が届いたw pic.twitter.com/80XqVaz9Em— ゆずたそ (@yuzutas0) 2018年4月4日 短い期間ではありましたが、インターン生である@sukukyonのメンターを務めました。 あまりメンターらしいことは出来なかった気もしますが、何とか無事に修了しました。 総論:最高のインターンだった 最高のインターンで最高にやっていきを発揮して最高の成果を出しました。 ということで、概ね上手くいきました。 成功要因としては「関係者全員がお互いをリスペクトできたから」だと思っています。 非常に良い関係性を築けていました。 まず何よ
[プロフィール]石川 洋資 (@_ishkawa) | 10X inc. Co-Founder, CTO 面白法人カヤック、LINEでの複数の新規事業開発を経て、メルカリ/ソウゾウへ。 メルカリ/ソウゾウではプリンシパルエンジニアを務める。オープンソースプロジェクトへの参加や執筆活動も行っており、2017/2には「Swift実践入門」を出版。 「大学卒業後、カヤック、LINE、メルカリで新規事業の立ち上げを経験した後に、メルカリの同僚だった矢本さんと会社をつくることに。モノをどのようにつくるかも重要だが、それ以前に何をつくるかが重要だと痛感していたところで、一緒に答えに辿り着けそうな人に誘ってもらえたのが起業を決意したきっかけ」 立ち上げ時はiOSアプリのUI検証に集中 プロダクトが人の役に立つものになるかどうかは、実際に人が使ってみるまでわからない。そんな状況を考慮して、「タベリー」開発
bonfire frontendで発表した今後のフロントエンドの話です。
10分で生産的なミーティングができるWebサービス「minmeeting」を開発している伊勢川です。 本日は、これまで連載で紹介してきた2年目〜5年目エンジニアが陥りがちな症状と予防を要約して、まとめ記事を書きました。 網羅的にパターンを洗い出した訳ではなく、たまにそういうやつおるなという「おるおるネタ」の7選です。 若手エンジニアの皆さんは、ぜひこのようなくだらない失敗を繰り返すことなく、よりよい20代を過ごしていただければと思います。 Google依存症 Googleを調べれば何でもでてくる便利な時代が生んだ症状です。 症例 エラーログをGoogleで調べて出てこなかったら、それは解決方法がないと思ってしまう。 新しいことをやろうとして、Googleに実現方法が書いてなかったら実現不可能と思ってしまう。 予防法 Googleは日本語が苦手なので英語で聞く。 Googleで見つからない解
Webエンジニアを8年くらいやっていて、なんとなく、一通りのことはできるようになってきた。ただ、ちょっと得意な分野もあるとはいえ、基本的になんでも屋さんとしてやっているので、技術者としてのアピールがいまいちだなーというのが気になっている。そこで、技術者としての自分をアピールできそうな技術テーマを一つ選んで、それにじっくり取り組んで見ようと考えた。 しかし、取り組む技術テーマをうまく選ぶ自信がない。そこで、ちょっと作戦を考えて取り組む技術テーマを見つけようと試行錯誤してみたので紹介してみる。 ステップ1: 指標を考える やっていく技術テーマを見つけるにあたって、テーマの候補をスコアリングしてみることにした。漠然とスコアをつけるのは難しいので、自分が普段技術テーマに取り組むかどうかを考えるときに気にしていることを思い出して、5つの指標に分解してみた。 指標1: 自分の興味 自分がおもしろい、や
こんにちは。 Android/React-Nativeエンジニアの@kiriminです。 以前、Kyashブログで紹介されていた、B1グランプリという取り組みがとても素晴らしいなと思ったので、Kyashチームをリスペクトしているpaymoチームでも対抗して(?)バグバッシュ大会を開催してみました。 バグバッシュ大会とは基本的にはKyashさんでのやり方を参考にしたのでそちらを見て頂ければと思います。 ざっくり説明すると、みんなで時間をとってアプリを触ってバグを探し、報告数を集計して表彰したり検出されたバグを皆でワイワイ眺めたりする会です。 やっていき方「やりたいね〜」だといつまでもやれないと思ったので、わりとエイヤでゴリ押ししました。 大会のようす多くの人の時間を長く確保するのは難しいので、開催時間は一旦30分にし、15分でバグを見つけ、15分で振り返るというスケジュールにしました。 初回
HERPの技術発信の場として、HERP TechHubをリリースしました。会社のドメイン上ではなく、個人のブログのHubとしてのページを作成する形をとっています。 それに至った背景について書いてみたいと思います。 TechBlogのあり方を考えてみるTechBlogの目的と内包している問題について、エウレカでTechBlogの開設・運用をリードした経験から得られた課題も踏まえて考えてみる。 TechBlogの目的 従来のTechBlogの開設・運用の目的は以下の3つにまとめられると思う。 ブランディングを通じた採用力の向上エンジニアの個人ブランディングエンジニア全体・技術貢献ブランディングを通じた採用力の向上 エンジニア採用においては情報発信は欠かせない。もちろん一番大事なのは良いUXを提供できるプロダクトを作り、その品質を上げていくことだが、それだけでは社外の人間からして技術への考え方や
合同会社テンマドで代表社員をしています山岡です。基本はPHPやNode.jsのエンジニアですが、社外CTOや技術顧問など、アドバイザーとしていろいろな会社のお手伝いをしています。 情報の共有から始める アドバイザーとしてのご相談をいただく場合、そもそもまだ社内にエンジニアが数人しかいなかったりして、この先どうチームとして育てていけばいいのかわからない、その部分を手伝ってほしい、というケースが多いです。 その場合、どこから始めるかというと、情報の共有と見える化から始めることが多いです。esaなどMarkdown記法で気軽に書けるドキュメントツールを利用して、どんな些細なことでも書くようにしてもらいます。例えばサーバーでの作業計画とそのログ、フレームワークやライブラリの使い方など。 書くハードルをどうやって下げるかがポイントです。考え途中や調べ途中のものであっても、とりあえず書いて共有する癖を
皆さん、こんにちは。CTO室の責任者をしている梶原です。 eureka, Inc.で運用していたエンジニア・ブログを自社で運営しておりましたが、Mediumにリプレースしました。 同じような事を検討している方がいらっしゃれば参考になるかと思い、MediumにStoryを残させてもらいます。 解決したかった課題はなんだったのか以前はWordpressで実装しておりました。執筆者として、また管理者としての観点で、以下のような課題がありました。 執筆者としての課題執筆者が執筆開始までに実施すべきタスクが多く、執筆することの心理的なハードルが高い。執筆者にとって、Wordpressの入稿のインターフェイスは手軽ではなかった。イメージの縮小・拡大やスライドなど埋め込みで表示するには、HTMLをベタ書きなどがあった。(当然書くのは良いんだけど、面倒くさいって意識)ラベル、カスタマイズフィールドの入力方
エンジニアはコーディング技術や実装力だけを磨けばいいわけではなく、デザイナーはビジュアル表現力だけを高めればいいわけではない。ビジネスにおいて求められるのは何であるかを考え、常に問題解決を行う意識で臨まなければならない。それはエンジニアもデザイナーも皆同じだろう。 現在、テスト公開後のフィードバック対応を進めているが、ふと気付くとリストに書かれたタスクをこなすだけの作業になってしまい、提案や問題解決の視点が抜けていた。 クライアントがその要望を発するのには、理由や背景が存在する。背景に何があるのか、何が求められるのか、要望を実現するためにはどう動くべきかという点に対し、プロとしてユーザー視点も忘れず、業務フローの組み立てまでも自分の責任範囲で行っていくべきだ。ただの修正作業にしてはいけないし、ディレクターの指示を待っているだけでもいけない。 これはそのまま社内やチームとしての取り組みにも当
こんばんは野球エンジニアです. 「CTO」という肩書は僕の場合に限り「野球エンジニア」のエイリアスです.*1 この写真は,登壇準備直後見事にガララーガガラガラ*2だったB会場の様子です. なお,結局空席目立ちましたがすっごくいい気持ちでお話をさせてもらいました. ※写真はモブプロでおなじみの@TAKAKING22さんから提供いただきました,thx! DevSumi 2018運営の皆さまありがとうございます! 縁あって初めて登壇させて頂いたDevelopers Summit 2018の発表をちょっとふり返りつつ,「発表の補足・言えなかったこと」および、「はじめてのデブサミ」にフォーカスを当ててふり返りたいと思います. TL;DR 私の話は「セルフプロデュース」じゃなくて「生き方」の話でした(エンジニアとしての) 他人事(ひとごと)・余所事(よそごと)で盛り上がりすぎるのはやめよう,というのが
インターネットの上ではhmskと名乗っている者です。現在はアメリカはサンフランシスコにあるIndiegogoという会社で、同名のクラウドファンディングプラットフォームサービスに関するソフトウェア開発に従事しています。 Indiegogo: Crowdfund Innovations & Buy Unique Products 私が初めてアメリカを訪れたのは、2009年。大学4年生のときでした。その後、特に留学や出張の機会、海外志向があったわけでもなかったのですが、キャリアの分岐点で進む方角を何となく選んでいるうちに、今の場所に辿り着いていました。 サンフランシスコ、ひいてはシリコンバレーでのソフトウェア開発の仕事と聞くと、今ならとても高い給料や家賃が話題の中心になるかもしれません。初めて私が訪れた当時は、Apple、Google、Dropbox、GitHubといった会社が集まるこのエリアは
manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう? ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう? これは自戒をかなり含むが不満をSN
言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的に成り立ってしまっているので、それ以上成長をする必要がないのです。 まあ、そういう生き方もありかな?って思うので、それでいいやって思う人は続きは読まなくてもいいかなって思います。 ここから先はエンジニアとして技術を伸ばすことが楽しい、ものを作ることが楽しい、
勉強を始めた頃にこういう系の記事を色々と読んで参考にしたんだけど(これとかこれとか)、日本語でもあるのか探してみたときにあまり具体的なのは見つからなかったので書いておきます。 ※ 以下は主な勉強内容をかなりシンプルにしてまとめたもので、実際にはよく迷走していたし、この他にも細々と色々勉強してました。使った教材は全部英語だけど、英語できなくても大体の流れ&期間を知る参考にはなるかと思います。 HTML/CSS & JS 超基礎(2月〜4月)仕事辞めるキャリアチェンジするプログラミング勉強する!と決めたのが2月。ブートキャンプに行くべきか自分で勉強するべきか、色々考えた末に自分で勉強することに。仕事を辞めるまで2ヶ月弱あったので、まずは勉強する習慣を作ろう、本当にこれをやりたいと思えるのか試そうとしていたのがこの期間。 最初にCode SchoolのHTML/CSS, JavaScriptの有
こんにちは、SPEEDAのSREチームでエンジニアをしている阿南です。SPEEDAのSREチームでは、昨年末kubernetesについて理解を深めるために合宿を行いました。やり方はA〜Cの3チームに分けて、それぞれのチームでkubernetesに関することを調査、構築するという形式で、今回はAチームが実際にやってみた内容についてブログを書きたいと思います。(それぞれのチームでかなりボリュームがあるので、複数回に渡って連載的な形でお届けしたいと思います。) Aチームでは、kubernetesを本番環境に投入するにあたり、ログ収集周りをあまり調査できてないなと感じ、GCP上に環境を作ってみることにしました。 構築する環境 構築手順 クラスター構築 wordpress + MySQL構築 Fluentdイメージの作成 ConfigMap設定 DaemonSet設定 まとめ お知らせ 構築する環境
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く