O'Reillyサブスクリプション和書まとめ - kawasimaサイトの検索導線からも全部見えるようになったようです。 マスタリング・イーサリアム ―スマートコントラクトとDAppの構築 https://www.oreilly.com/library/view/-/9784873118963/ 初めてのGraphQL ―Webサービスを作って学ぶ新世代API https://www.oreilly.com/library/view/-/978487311893
インフラ担当がいない、地方で根深い「バックエンド軽視」の闇
経営者：「インフラも見ることができる、良いITエンジニアがなかなかいないんですよ」 ITエンジニア：「インフラ？ 勘弁してください。二度とやりたくありません……」 これは、経営者とITエンジニアの間に見られる乖離（かいり）である。筆者の経験では、特に「地方都市」でこの傾向が強い（具体的な都市名を挙げると無用な波紋を生み前向きな議論が進まないため、あえてぼかすことをご理解いただきたい）。 両者の溝はどのようにして生まれるのか、どう向き合うべきか。今回はこのテーマについて考えてみたい。 「開発ありき」「作ってなんぼ」、そもそもインフラ業務が認知されない Webサイトやアプリケーションを作っておしまい。サーバーやデータベース、ネットワークなどバックエンドのことは気にしない。あるいは意識から漏れる。いわば、「フロント重視」「バックエンド軽視」の状況を悪気なく作り出す。 その背景には「見えないものを
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点 - Qiita
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点 この記事を書くに至った経緯 僕が代表をしている株式会社KOSKAでは製造業の原価管理をIoTで自動化するGenkanというサービスを提供しております。 そんな弊社では半年前、バックエンドをRuby on RailsからScalaに移行したのですが、その効果が思ったよりだいぶ大きく、いずれこの効果を共有したいなーと思っていました。 弊社ではスタートアップで全員ほぼ未経験状態のScalaを採用するという挑戦をした結果、「Scalaを書きたい」というレベルの高い人材をかなりの確率で捕まえられるようになり、開発がものすごい加速した上に堅牢になったのでそのうちスタートアップでScalaを採用するメリットを記事にする予定。 https://t.co/uqZ5YWs6Ru — ソネケン (@
マネジメントレスのススメ - VPoE-Meetup by manaboo
2019-03-26 成長するエンジニア組織のマネジメントについて語ろう https://manaboo.me/projects/16
エンジニア系広報の始め方と種類毎のメリット/デメリット｜nottegra@在宅勤務
DEVREL(Developer Relations)や技術広報というワードで聞いたことがあるかもしれませんが、プロダクトやエンジニア組織の認知度向上を目的として、各社でエンジニアブログや勉強会をやったり、カンファレンスのスポンサーになるなどを目にすると思います。が、いざやってみよう！となると何から始めれば良いのかや、実際にどういったメリット・デメリットがあるかは分かりにくいです。 僕がさまざまな技術広報に取り組んだ経験から、所感ではありますがメリット・デメリットを踏まえた内容をノウハウとしてまとめます。 自社メディアへのエンジニア系記事掲載Wantedlyやコーポレートサイトなど、自社が抱えるCMS上で作成する記事のことです。エンジニアブログも該当しますが、後述します。 [メリット] 1. 書いてすぐ世の中に出せる、かんたん 2. 顕在層(興味を持ってくれた人)が参考にしてくれる [デメ
成功したエンジニア組織施策とその裏にある導入背景｜nottegra@在宅勤務
まぁ長く続くとその分マンネリ化は避けられないので適宜テコ入れをする必要はあります。。。 若手エンジニアキャリア相談ビアバッシュ 細かいことは過去ブログにしているので参照。ここではブログに書かなかったことを説明します。 [概要] 新卒1～2年目の若手と中堅エンジニアが参加し、自己紹介や今までやってきたプロジェクトについて全員がLTを実施。終わったらそのままキャリア相談という名の懇親会(飲み会)に突入。 [導入背景] 若手エンジニアが中長期のキャリアに悩んでいることが多く、マネジメント側(自分)からあれこれ助言しても決めあぐねる状況が見られました。自分のキャリアに関するイメージが薄いと短いスパンでの目標設計しか出来ないので、マネジメント側からしてみると評価が難しいことがありました。 原因として大きいのは参考にできる情報が圧倒的に少ない事なので、身近な人のナマのキャリア遍歴を効率良く情報収集する
失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
フロントエンドの情報収集について - Qiita
2020/07/17: いくつか追記しました はじめに 私は、TechTrainでフロントエンドのメンターとして面談する中で「最近フロントエンドの勉強を始めました！」という方や、フロントエンドエンジニアを目指す学生と話す機会が何度もあります。 その中でよくある質問が 「フロントエンドの情報収集ってどうしてますか？」 です。 何度も質問を貰うので、気になる人は多いのかなと思います。 この記事では「私がどんな風に情報収集しているか」を紹介しようと思います。主に情報収集の流れと、どこからフロントエンドの情報を集めているかについてです。 情報収集の流れ まずは情報収集の流れとして主にプロセス的な観点で整理してみます。 私の情報収集を抽象化すると以下の3つのプロセスがあると思います。 情報源から情報を集める(ex: Twitter, Blog, Qiita) 特定の場所に情報を溜める(ex: はてな
【7月7日は創立記念日！】「ブログを書く」ということ | DevelopersIO
クラスメソッド AWS 事業本部コンサルティング部の丸毛（まるも）です。 7月7日はクラスメソッドの創立記念日ということで、今日は「ブログを書く」ということについて、普段はあまり書かないポエムとしてしたためたいと思います。 22,000 本のブログのはじまり 執筆時点で公開済み本数を確認したところ、「22,040 本」となっていました。 Developers.IO は2011年7月1日の福田の記事にはじまり、記念すべき技術ブログ 1 本目は社長の横田による S3 の記事でした。 私はクラスメソッド在籍2年7ヶ月目になったわけですが、この記事で 186 本目になります。（更新にラグがあるのでチョット少なく見えているのは、ご愛嬌） 16期（2019/7/1〜2020/6/30）では念願の年間 100 本（102本）を達成することも出来ました。自分なりに「よく書いたな・・・」と感じるものの、De
DeNA1年目エンジニアが語る、社会人になった僕らの変化 -学生時代の自分に言いたいこと- | BLOG - DeNA Engineering
2020.07.04 新卒研修振り返りレポート DeNA1年目エンジニアが語る、社会人になった僕らの変化 -学生時代の自分に言いたいこと- by Atsuhi-Otsubo Takuko-Sato Shinjiro-Sugita 2020年7月4日(土)-7月5日(日)でサポーターズ主催の 技育祭 という、「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスが開催されています。こちらでDeNA はプラチナスポンサーとして参加しています。 このうち 2020年7月4日(土)に、DeNA新卒1年目のエンジニア3名が登壇しました。こちらの記事でその登壇の内容をご紹介します。 4月から7月までのエンジニア研修を終えた彼らがどう変化したのか。学生時代の自分に伝えるなら何を伝えるのか。等身大の彼らの言葉で語っています。主なトピックは以下です。 エンジニアに
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える - エンジニアHub｜Webエンジニアのキャリアを考える！
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える 技術的負債、デザイン面での課題など、サービスを構成するシステムを全面にわたってリニューアルしたプロセスを、オミカレの高橋一騎さんが克明に伝えます。 株式会社オミカレでテックリードをしております、高橋一騎（たかはし・いっき／ @ikkitang ）です。私たちが提供する婚活メディアサービス「オミカレ」は、2019年3月にシステムのフルリニューアルに踏み切りました。本稿では、このリニューアルのプロセスをできるだけ詳細にお伝えしたいと思います。 さて、「技術的負債」という言葉を耳にすることがあります。なぜ負債が生まれるのか。「品質を犠牲にしてでも早々にサービスをリリースし、短期的にビジネスの速度を上げる」という判断はその理由の一つに挙げられるでしょう。エンドユーザーへの価値提供スピードを得るための見返り
LINEの新卒エンジニアが入社後どのような数ヶ月を過ごすのかご紹介！研修のお題は「LINEクローンを作る」 - LINE ENGINEERING
LINEの新卒エンジニアが入社後どのような数ヶ月を過ごすのかご紹介！研修のお題は「LINEクローンを作る」 By Yusuke Kushii | 2018.06.11 2021.01.08Developer RelationsチームでCulture Evangelistをしています。LINE Engineering Blogや技術イベントなどを担当。 こんにちは、LINEでCulture Evangelistをしている櫛井です。 今回はLINEに新卒エンジニアとして入社した場合、どのように最初の数ヶ月を過ごすのかご紹介したいと思います。 はじめに LINEでは新卒採用を2013年から開始し、その後、採用数は年々増加しています。技術職は、開発/データ/インフラ/セキュリティの4職種でエンジニアを採用しており、オフィスも東京・福岡・京都の3拠点から選択が可能です。 本年度の新卒研修では技術職2
あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える - エンジニアHub｜若手Webエンジニアのキャリアを考える！
あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える エンジニアがサービスのアイデアを思いつき、それをリリースするまでにはどのような過程があるのでしょうか。情報共有ツール「Kibela」が世に出るまでのフローを、起業した井原正博さんが詳細に振り返ります。 ヤフーやクックパッドでの開発を経て、ビットジャーニーで代表を務める井原正博（いはら・まさひろ／@ihara2525）です。プライベートで超長距離のランを楽しむかたわら、情報共有ツール「Kibela」の開発・運営を手がけています。 Kibela - 個人の発信を組織の力にする情報共有ツール 「Kibela」は僕自身が2015年に起業して立ち上げたサービスですが、この記事では、僕がサービスをいかに開発したか、その方法からリリースまでの過程を振り返りつつ、サービスの現在の状況までお伝えします。 「自分でもサ
社内障害情報共有のススメ - Hatena Developer Blog
こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今日は社内で数年ほど取り組んでいる障害情報の社内共有についてご紹介したいと思います。 障害情報を社内共有する理由 サービスを運営しているなら、出来る限りサービスが一時的に止まってしまうなどの障害を起こさないように事前に対策を取るなど気をつけるべきです。しかし、どれだけ事前に対策をとっても、急激なアクセスの増加や、意図しないバグの混入、オペレーションのミスなどを理由として、障害を起こしてしまうことがあります。 障害が起きた時、それに暫定的に対応して終わりとしてしまうことも多いです。しかし、復旧した後大事なのは、障害に対して適切に振り返りをし、同じサービスで同様の理由で障害を起こさない、また社内で同様の理由の障害を未然に防ぐことです。 そこで、はてなでは障害の暫定対応をした後は、障害の振り返りや他チームへの知識共有のために
人工衛星開発から学んだエンジニアにとって重要なこと - Qiita
前例がないため、どこにも答えが存在せず、基本的に色々なものを１から考えて作ることが多くなります。 その時重要になってくるのが、と、 キャッチアップ力 と 基礎理解力 だと思っています。 私の場合、衛星が撮影した画像を処理して蓄積する処理をVHDLで組むというのがあったのですが、全くVHDLを知らない状態から1ヶ月半ほどで実装する必要が生じ、何とか間に合わせたという経験がありました。 その時は、基本的な知識を本やWebから調べ、回路を組みながらあれこれ試して勘所を掴み、最終的に実装に落としていくというような事をしましたが、昨今テクノロジーの進化と変遷が激しくなる中で、未知の技術を学習して「使える」状態に持っていくための、 自分なりのフレームワーク を持っておくことが非常に重要であると思っています。 逆に言うと、何かした時に、常にそれを自分の中にフレームワークとして蓄積するという意識を持って取
1人インフラチームで、 自動化の時間を確保するために やっている（た）こと
SRE-SET Automation Night で話した内容です。 https://connpass.com/event/71497/
エンジニアのベンチャー企業の選び方/働き方/やめ方 - mizchi's blog
この記事は退職者アドベントカレンダーの12日目です。 adventar.org 経歴としては、新卒で設立してすぐのゲーム会社 => 小規模教育系ベンチャー => Incements(Qiita) => フリーランス。 今年で29歳、20代で3回退職しました。20代のうちは冒険してベンチャー企業で働いてみよう、と思ってたのですが、結局29を目前にフリーランスになってしまいました。 ベンチャーで働くこと ベンチャーで働くのはリスクを取るということ。一番言いたいのは、ストックオプションもたずにベンチャーやるな、ストックオプションも確実に換金できるわけじゃない、ということ。上場するときに行使するか、バイアウト時に買い取ってもらわないといけません。 また、ストックオプションの期待だけ給与は下がるので、他の会社で同じことをやるのに比べて、 -100~-150万ぐらいの相場です。少数精鋭志向で最初からじ
チームの生産性を上げるために新規事業チームがやっていること - Gunosy Tech Blog
こんにちは、新規事業開発室のエンジニアの@__timakin__です。上記は生産性が全く上がっていない様子です。 forkwell_meetupというイベントにところで「チームの生産性を上げる的な話をしてください」というフリをされたので、偉そうな話をして来ました。 forkwell.connpass.com 発表について スライドは以下の通りです。 speakerdeck.com 冒頭の方に実際のSlackのチャンネルやカレンダーの様子を載せましたが、だいぶフランクにやりとりが行われています。 新規事業へもともと興味がある人間が集まると、そこまで強制しなくてもリサーチする流れが生まれますし、逆に言えば採用の段階で新規事業の立ち上げコストというのは決まってくるのだなと思います。 生産性とは 生産性とはなんぞやという話だったのですが、僕個人として言いたいのは「生産総量ではなくて投資効率性ですよ
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AndroidエンジニアがRailsにチャレンジしてる理由
