マンガではわからない ソフトウェア開発の真理 | ドクセル目指せ脱UE4初心者！？知ってると開発が楽になる便利機能を紹介 - DataAsset, Subsystem, GameplayAbility編 -
ソースコード流出事件、原因はモラルの欠如 GitHubをもっと使え
大手企業のソースコードが「GitHub」に流出したことが話題になっている。誤解してほしくないのは、今回の件でGitHubは全く悪くないことだ。問題はモラルハザードにある。モラルを売ると金になる構造に加担してはいけない。 話題のソースコード流出事件、報道にちょっと疑問 筆者は普段、深圳の開発ボードスタートアップ界隈（かいわい）にいて、それに関連する記事を書いている。今回は日本の話だが、編集部からリクエストがあり、かつ筆者自身も書きたいと思った。著名な企業・組織のシステムのソースコードが、共同開発サービスのGitHubにアップされた件である。 「Twitter」などでの情報を見る限り、かつて多重下請けでプログラムを書いていたエンジニアが、手元のソースをうっかり共同開発サービスのGitHub上に、誰でもソースを見ることができる設定で公開してしまったらしい。三井住友銀行など大企業のものとみられるソ
自分の書いたコードが他者によって書き換えられることにショックを受けてしまうひともいるって話「まずこういう感情を理解する必要がある」
irof @irof 自分の書いたコードが書き換えられることにショックを受ける人ってのはたくさんいて(もしかしたら多数派かも)、コードというかなんでもなんだろけど、「訂正」された、誤っていたと捉える。そもそも誤りでもないんだけど、仮に誤りだったとして、だからどうしたと、、、まだ掘らなきゃか。 2020-09-06 10:52:42
2020年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。コネクト支援チームの@tignyaxです。 みなさま、夏はどう過ごされたでしょうか？ 私は、夏が好きなのに今年は夏らしいことが出来なくて寂しいなぁとなっています。。。 さて、今年2020年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2020年のエンジニア新人研修について 基本的には2019年と同じ形*1での実施となりました。 最初の1週間で必修講義をしたあと、新人の皆さんには2週間ずつ3チームを体験してもらいました。 チーム体験のコンセプトは、新人に「興味のあるチームで実際に業務を体験し、配属希望を決める参考になった。」と言ってもらうことです。 各チーム体験では座学や研修を中心にするのではなく、業務体験が中心です。 チーム体験を通して、配属先を検討する材料にしたり、いろんなチーム/人/業務を知ってもらえる機会となります。 必修講義 誰に: 開発/
Qiitaの「いいね」が「LGTM」に変わります - Qiita Blog
こんにちは、Qiita開発チームのgetty104 です。 今回は2020/03/12にリリースした、QiitaのLGTM機能について、その背景と目的を説明します。 背景QiitaについてQiitaは2011年にリリースして以降、ありがたいことに順調にユーザー数が増えていき、2020年の現在では毎月700万人を超えるユニークユーザー（UU）が訪れ、6000万PVのページアクセスがあり、毎日300件以上の記事が投稿されるようになりました。エンジニア向けWebメディアとして業界トップシェアを獲得し、国内エンジニアのほぼ100％が利用するサービスとなっています。 Incrementsの全社戦略IncrementsではQiitaの他に、エンジニア向け転職支援サービスであるQiita Jobsや、社内向け情報共有サービスであるQiita Teamも開発・運用しています。また今年、Qiitaのオーディ
「仕事で成長」って、本当に必要ですか？
何か月か前の話で申し訳ないんですけど、「まなめはうす」のまなめさんっていう、コーラばっかり飲んでる変な人がこんな記事書いてたんです。 部下の教育に失敗した話 そう思う私だからこそ、部下には学ぶ時間さえ与えれば成長できると思って、業務を進めなくてはいけない立場でありながらも、可能な限り時間をつくってあげたんですよ。 部下になった時点で数か月後には別のPJに異動することも決まってたこともあって、そのための準備とかスキルアップとか必要と思って。 結論から言うと、私が作ってあげた時間は無駄に終わり、後日本人からも、もっと仕事をふって欲しかったと言われたのですが。 これ、実は私も同じようなことしちゃった、正確にはしかけちゃった経験があるんですよ。 前の会社の時の話なんですけどね。 その会社って、あるプロジェクトが終わると即他のプロジェクトにアサインされて、「隙間の時間」的なものが本当に全然なかったん
やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
プログラミングスクールへの期待と提案について - ペパボテックブログ
CTOのあんちぽです。このエントリでは、昨今隆盛しているプログラミングスクールに対して期待していることと提案について、エンジニア採用を担当する者として述べたいと思います。 このエントリの前提としての私の考え まずCTOとして、プログラミング教育全般に対する私（およびペパボとして）の考え方を述べます。我々は「いるだけで成長できる環境」を謳い、エンジニア教育に熱心に取り組んでいる企業であると自負しています（少なくとも相対的には）。また、インターネット産業の担い手として、この業界に多くの方がエンジニアとして活躍の場を見いだせることを心から願っていますし、微力ながら貢献してもいると思っています。 そのような我々ですので、昨今のプログラミングスクールの隆盛について、非常に好ましく思っています。特に私のような世代は、見様見真似で必死にやってきてなんとかいまがあるという感じでプログラマになりましたが、昨
エンジニアの能力と今どきの難しさ
エンジニア（ここでは主にプログラマー）に必要な知識や経験って、ざっくりベース、カテゴリ、実行環境というレイヤー分けられると思ってて、それぞれに対してはだいたい以下のような定義で考えている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの低レイヤー②カテゴリ フロントエンド / バックエンド / クライアントアプリなど③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど最近の潮流で言うと、③の部分から入る人が多いと思う。 ③は比較的習得が楽なこともあって、初心者がプログラミングを始める際には一番コストパフォーマンスが高い。中身はブラックボックスであってもなんとなく動くものは作れるので、自己満足にしろ仕事にしろ成果として見えるものにはなる。 ただし、流行り廃りが速く、手を動かし続けないとキャッチアップしていけない。 ①は習得するのに時間かかる。その
クソコードはエンジニアを貧乏にする｜ミノ駆動
何が書かれているのか理解が難しく、イレギュラーな方法で裏技的に実装され、ちょっと触ればバグと化す、クソコード。 プログラマ諸氏なら誰しもが見たことのあるクソ忌々しいアイツだ。 クソコードはエンジニアを貧乏にしてしまう。 なぜ貧乏になってしまうのか、その理由について、怒りをぶつけながら以下に書き連ねる。 本記事の構成■理由①：プロダクトが利益を出せなくなる ■理由②：エンジニアが資産蓄積できなくなる （←ココ重要） ■クソコードを滅ぼし豊かになろう ■ソフトウェア開発に携わる方々へ 理由①：プロダクトが利益を出せなくなるまずこちらの理由は簡単だ。３項目に分けて説明する。 【クソコードは読みにくい】 どんなロジックなのか理解が容易ではない。ロジックそのものは簡単であっても、tmpと名付けられた正体不明な変数、非推奨なAPIによる意図不明な実装などにより、読み解くのを難しくさせてしまう。 「クソ
コンピュータサイエンスの基礎を学ぶと何ができるようになるのか｜masuidrive｜note
今日、Facebookに「プログラマだったら当然知ってるよね？という知識一覧」という記事で、「データ構造」や「計算量」から「理論計算機」など幅広くコンピュータサイエンス(CS)の基礎をプログラマ知っているべきという論が展開されています。 私は経営学部だったのでコンピュータサイエンスについて学校で習ったことはないのですが、高校の頃から趣味で色々調べていて、この中だとグラフ理論と機械学習系以外は大体理解しています。 「Web系の人って、新技術ばっかり追いかけてCSの基礎とかちゃんと学んでないよね」っていう話は他でも時々聞く気がします。 一つがWeb系のエンジニアは情報系の大学を出てない人も多いことと、実際あまり役に立つシーンがないのではないかと思います。 実際、CSの基礎ができると多くのエンジニアにとって何のメリットがあるのでしょう？ 一番は「先の技術を読めるようになる」ことです。 ITの世界
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
退職エントリーを書かれる前に実践したい、エンジニアが辞めないチームの作り方
採用難に苦しむIT企業でマネジャーをやっている皆さん、こんにちは！ プログラマーにして採用担当、菌類のくせに人類を採用、育成している「きのこる先生」です。 普段はIT企業で働くエンジニアの皆さんに転職やキャリアについてお話していますが、今回は担当編集からのリクエストで、そんなエンジニアたちのマネジャーとして日々奮闘している皆さんに向けてのお話です。 エンジニアに「辞めます」と言われたら いきなり胸が苦しくなるような見出しですが、今回のテーマは「エンジニアの退職」です。 皆さんはマネジメント対象であるエンジニアから「辞めます」と言われたことはありますか？ 菌類は、あります。それはもう、数え上げたらキリがないほど……。 どんな理由であっても、チームのエンジニアが辞めるのはつらいものです。目の前の仕事には影響が出るし、残されたチームメンバーも何だかざわついてしまいます。「今までのマネジメントは間
ZOZOからSUGARに入社しました！！ - 可愛いScala書きたい人の日記🌟
Tl;dr: ZOZOでテックリード => SUGARでScalaエンジニア やりたいこと全部できて最高 転職はダイエット効果あるかも？！ だれ？： この人です。SUGARパーカーもらって喜んでいます← 初めまして、ダーシャです！ ZOZOテクノロジーズでScalaプロダクト全てのテックリードをやっていました。今年からSUGARでScalaエンジニアやっています！ Scalaが大好きで、今はCats Effectとかhttp4sにハマっています。自分のミッションは型安全性・可読性・テスタビリティ・メンテナビリティの高い、可愛い可愛いScalaを書くことです！！ 転職活動していたときに重視していたこと： - ワークライフバランス - 可愛いScalaが書ける - 成長ができる・気になる技術に触れる 何をやっている会社？： ライブストリーミングサービスです。 普通のライブストリーミングアプリは
技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
日本経済新聞社を退職しました - 銀色うつ時間
いわゆる退職エントリ。興味のない人は閉じるボタンを。 11月末で日本経済新聞社を退職した。2年8ヶ月という短い期間だったが、素晴らしい経験をさせてもらった。 やっていたこと 日経に入社して、日経電子版のwebを新しくモダンなアーキテクチャで作り直すプロジェクトの立ち上げから参画した。これは現在r.nikkei.comというドメインから配信されている。 r.nikkei.com 結局退職までこのプロジェクトがメインの仕事になったわけだが、最後まで全く飽きることはなかった。技術的な面で飽きずに働けるということはエンジニアにとって簡単なようでいて難しいことで、それができたのは最初のアーキテクチャの設計が優れていたこと、特定のフレームワークやライブラリに過度にロックインさせないポリシー、新しい取り組みにどんどん挑戦していけるカルチャーや環境（これは単純に人手不足という話もあるかもしれない）があって
NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
フロントエンドエンジニアから、デザイナーさんに意識してほしい10のこと｜Pittan｜note
フロントエンドエンジニアとデザイナーさんは日々協力してプロダクトを作っていく関係にあります。デザイナーさんが作ってくれたものをエンジニアが素早く実現できるよう、いくつかエンジニアから意識してほしいことをまとめました。 なんでこんな話になったのか（前置きなので次の章まで飛ばしてOKです） デザイナーさんから「この画面をこんな風に作ってください」とXDやSketch、PSDなどいろいろな形で渡されることがあると思います。 僕の個人的な意見・経験ですが、いざ実装するぞとなったときに 「あれ…ここってどうしたらいいんだろう？」 と迷って作業のスピードが落ちてしまうことがとてもストレスに感じていました。できればノンストップでいきたいなあと思うわけです。 手が止まるたび、デザイナーさんに「ここってどうしたらいいですか？」と質問するのが何か新しい画面を作るときに必ず発生していました。 「（いつも聞いてる
エンジニア採用が変化してますよ。という話｜Kazuhiro Chida
こんにちは、HR TechスタートアップでHRをしています。なんだかんだで、採用という領域に14年くらい関わっています。 ここ最近、IT/Webエンジニア採用において大きな変化を実感していて、それに対して経営者や人事の変化が少ないな、と感じていたので記事にします。 願わくば、エンジニア採用をやっている企業の経営者や人事の役に立てば幸いです。 変化さて、その大きな変化というのは、採用企業と求職者間における情報量の逆転です。変化の傾向自体はずっとあったのですが、ここのところ閾値を超えた感じがあります。 数年前のソシャゲブームのときも、求人倍率としては求職者が優位ではありました。それでもまだ当時は採用企業のほうが情報強者で、待遇につられてブラック企業に入ってしまうエンジニアが多かったのを記憶しています。 それまでは求人情報といえば、求人広告やエージェントから伝えられる情報をもとに求職者が判断し、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shiodaifuku.io
