1. ギークの遺伝子なんてないことを心に留めようよく、「プログラミングには得意不得意がある(some kids get it, and some kids don’t)」とか、さらには「プログラミングには向いていない子がいる」とか聞きますね。 大学のコンピュータサイエンスの授業の成績分布が、とても良く理解できる生徒と何もわかっていない生徒にくっきりわかれる、という話も聞きます。本当でしょうか？Patitsasらの最新の研究によると、実際にはそんなことはなく、くっきりと成績の分布が分れてしまったコンピュータサイエンス入門のクラスは、5.8％に過ぎなかったそうです。 この論文では、「プログラミングには得意不得意がある」という迷信は、プログラミングを学びだしたときに躓きがちな生徒でなく（意識的か無意識的かにかかわらず）、スムーズに学ぶ生徒の方へ教える時間や熱意を費やすことにつながり、ひいてはコン

特集1では，2人1組になってコードを書くペアプログラミング（ペアプロ）と，チーム一丸となってコードを書くモブプログラミング（モブプロ）について解説します。… この中で、モブプロは モブプログラミングの「モブ」とは群衆のことです。モブプログラミングでは、ペア（2人）ではなく、モブ（チーム全体）でプログラミングを行います。モブの人数は3人から5人くらいを想定しています。ペアプログラミングと同様に、コードを書くだけでなく、すべてをモブで行います。 と説明されています。 私がモブプログラミングという言葉を初めて聞いたのは、現マイクロソフト牛尾氏の以下のブログ投稿だったように思います。

We are proud to launch the very first version of our open-source project for Anomaly Detection and Behavioural Profiling on data-streams, datastream.io (dsio on github). We have a long roadmap ahead of us, but, release often and release early, as they say. So here it is — a minimal viable full-stack Python anomaly detector: pip install -e git+https://github.com/MentatInnovations/datastream.io#egg=

今回言いたいこと・UIデザインとそれを書き起こすプログラミングの乖離は、いくらわかってるつもりでも想定より大きくなる ・工数や実装都合上、泣く泣く見た目を変えざるをえない場合のデザイナーのストレスは、スピード優先で設計がおろそかになったときのエンジニアにかかるストレスより大きいのではないか ・雑にプロトタイプを出していい時代は終わってるのでは？と思うので、デザインを勉強していくべき 「デザインを勉強したい」 学生の頃から、dribbbleやbehance、デザイナーブログをみるのが大好きで、「うわーこんなかっこいいロゴ思いつかないよ、すげー」とか、「フォントの微差によく気を使ってるんだなー」とか、「このサイトの余白は過剰だけど、こっちはいい塩梅だなー」とか、そういうのがかなり気になってしまうタイプでした。 というと聞こえがいいのですが、結果的にエンジニアの道を選んで、UIは実装しながら考え

tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に

TL;DR: This article series explains one of the fundamentals of drawing: how to draw three-dimensional things correctly. It’s an essential skill for artists, but it’s also a great first topic for coders that want to get started with art. Even better, we’ll learn it all by simply looking at video games (scroll to ‘Types of graphical projections’ if you’re antsy). Drawing correctly is not an artDrawi

はじめに このカレンダーは全部埋まりました。 Mastodon Advent Calendarに参加したい方は[次のカレンダー](https://adventar.org/calendars/2265)をご利用ください。 # なにこ… 12/24 の記事です。例に漏れず遅れた。 Mastodon が流行し、この世に新たな選択肢が増えたことが、いかに美しく、いかに尊いことであるかについて、改めて語るべくもないことであろう。しかしてそれは逆に捉えれば僕が絶望的な気持ちになるほどの出来事だったのだという前提も含め、今一度少しだけ駄文に付き合っていただきたい。 スタックから見る MastodonMastodon を構成する技術スタックは、得も言われぬほどモダンで、現代的で、クールなものだ。 フロントエンドは webpacker と React で構成され、バックエンドは最新の Rails が唸りを

また、人それぞれ見解が多少異なると思うので、同じタイミングであろうとも色々な方が書かれてみるのも面白い題材かなとも思っています( ´･‿･｀) それではiOSアプリ開発に必要な要素ごとにつらつらと書いていきます。それぞれ語りすぎるとボリュームが増えすぎるので、あえてなるべく浅めに書いていきます🐶 高性能なMacマシンを確保まず、技術的なこと抜きに一定以上の性能のMacマシンを用意するのが良いです。取っ掛かりの勉強目的などならともかく、中規模以上のアプリを作る場合低スペックマシンでは著しく非効率です。 大体以下のようなイメージで、これ未満だと早めにマシン変えた方が幸せになれると思っています。 2–3年以内に買った20万円以上程度のMacBook Pro: 許容範囲iMac 5K: 良い感じiMac Pro: 一般的なiOSアプリ開発ではオーバースペック気味でコスパは微妙かも🤔会社で、交渉

製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ

https://flic.kr/p/Tngybf, Credit: Some rights reservedこの記事は、ユーザーインターフェイス・デザインについて、私たちの「文化」がどのように関わっているのかということを考察してみるというものです。具体的な“アプリケーションのUIデザイン”に踏み込む前にまずは日本語の使われ方を観察し、そして海外の文化との比較を簡単に行ってみたいと思います。 はじめに今までにも私はユーザーインターフェイスにおける左右について考察したことがありました。Mac OSのウインドウについているクローズボタンはなぜ左配置であるのか。デスクトップアイコンはなぜ右配置であるのか。デスクトップの方については若干疑問が残る形となってしまいましたが、メニューバーが左寄せであることと狭い画面サイズが関係していそうであるというところまでは辿り着けたかなと思います。

問題意識エンジニアのタイプを分けるとき、大雑把に「サービス志向」と「技術志向」みたいな分け方をすることが、僕の周りではよくあります。 個人的にはこの分け方は必ずしも良いものとは言えないと思います。少しエンジニアのことをサービスと距離のある人種として捉えてるように感じるからです。 技術志向だからってサービスのことを考えてないということではなく、「よりセキュアな技術を採用する」「効率的で安全なデプロイができるフローを構築する」などなど、技術向上を通じてユーザー体験をよくしよう、としているはずです。 ただ、デザインを良くしたり読み込みスピードを早くしたりなど、「目に見える範囲で改善する施策」を考え、実行しなければ、プロデューサー的な人からすれば「何やってんだろうな〜」と、エンジニアはブラックボックス的な人に見えてしまうこともあると思います。 じゃあ他のアプリをいじってみたりして、サービス勘みたい