島本 大輔

英語コーチングサービスを提供する株式会社プログリットでプロダクト開発部部兼CTOをしております。 VimとHHKB愛用者(HHKB Studio持ってます)。

島本 大輔

英語コーチングサービスを提供する株式会社プログリットでプロダクト開発部部兼CTOをしております。 VimとHHKB愛用者(HHKB Studio持ってます)。

マガジン

  • プログリット 【tech blog】

    • 38本

    プログリットのプロダクト開発部メンバーによるテックブログです!

最近の記事

メモリの理解は大事

ソフトウェア・エンジニアとって低レイヤーの知識が大事かどうか、よく聞かれます。 直感的には大事だと思っているのですが、その理由についてなかなか言葉にできておりませんでした。低レイヤーと言っても幅広く、その中でも特に大事な部分があるのかな、と。 しかし、最近その中でも、コンピュータがメモリをどのように扱うかという部分は間違いなく大事だな、と思うようになりました。 以前はメモリが高価で貴重なリソースだったため、使い道やどこに割り当てられているかを意識することが重要でした。しか

    • 株式会社プログリットCTO就任のご挨拶

      こんにちは! プログリットの島本です。 この度、2024年6月1日付けで株式会社プログリットのCTO(Chief Technology Officer)に就任させていただきました。 プログリットでは「世界で自由に活躍できる人を増やす」をミッションに、より良い英語学習体験を提供しており、それをテクノロジーの領域から事業成長をリードするべく、今までにも増して尽力してまいります。 就任に当たり、プログリットがCTOを置くことになった背景と、今後のプログリットにおけるテクノロジ

      • コンパイルすることの楽しさ

        English version. 最近、ソフトウェアを自分でコンパイルするのに少しハマっています。 昔はコンパイルすると言っても、依存関係をダウンロードしたり、コンパイラの設定を細かく調整したりするのが大変で、手が出にくいものでした。少しでもエラーした場合は技術スタックを理解していないと太刀打ちもできないような状況でした。 しかし、最近はHomebrewのようなパッケージマネージャーが登場して、だいぶ楽になっている気がします。 (注:今回のブログでは、パッケージマネージ

        • コードにうまく歳を取らせる

          English version. IT業界で働いていると「うまく歳を取れていない」コードをよく目にすると思います。 どういう意味かと言うと、設計などの問題から、月日が経つにつれ、運用保守や機能開発などがどんどん難しくなるようなコードのことです。自分の経験から具体例を上げると… 利用しているバージョンのRubyがハードウェアのアップグレードにより互換性がなくなり、古いバージョンのRubyを独自コンパイルしないといけない。 もう開発が終わっている言語を書くために独自フォン

        マガジン

        • プログリット 【tech blog】
          38本

        記事

          学んでいる内容に浸る

          English version. 新しいことを学びたいとき、どうしますか?いくつかの方法が思い浮かびます。 みなさんは新しいことを学ぶとき、どうしていますか? 自分がやったことがあるものとしては… 本を買って一気に読む? オンライン記事を読む? コースを受ける? 動画を見る? という感じでしょうか。どれも効果的だと思います。 ただ、新しいことを学ぶ際に大事だと思うことが一つあります。 それは 学んでいることに浸ることです 。 「浸る」とは?自分が言っている「

          学んでいる内容に浸る

          仕事で嬉しいのはお金とは限らない

          English version. 普通に会社で働いていると報酬として給料が払われると思います。良い仕事をして、その報いとして昇給やボーナスがもらえる、あるいは会社の業績が良ければボーナスがもらえる、という感じでしょうか。資本主義の話なので当たり前なことではあります。 ただ、自分のキャリアを振り返ると正直あまりお金のことのことは覚えていません。もちろん、ボーナスや昇給、転職したときの給料アップなどがあったはずなのですが、そのときの気持ちをあまり思い出せません。 一方で、自分

          仕事で嬉しいのはお金とは限らない

          コードをコピーすることは必ずしも悪ではない

          English version. 最近は他の人のコード使うのが本当に簡単になったな、と思います。以前であれば、インターネットで検索したとしても、どこぞの掲示板に書いてあるコードだったり、どこぞにホスティングされているファイルをダウンロードしてくるようなものが多く、自分でなんとかして組み込まないといけませんでした。もちろん、バージョン管理もできなければ、先方で更新された場合に簡単に追えるようなものでもありませんでした。 それに比べ、最近のプログラミング言語にはだいたいパッケー

          コードをコピーすることは必ずしも悪ではない

          ボールを持ち過ぎないように

          English version マネジメントを経験したことがある方なら分かると思うのですが、マネージャーは基本的にタスクが多いです。マネージャーとして チームの取り組むべき課題を考える メンバーの成長を考える 1-on-1の実施 いろいろな会議への参加 稟議や勤怠などの承認 ツールの権限設定 などがあります。 また、会社の規模がそれほど大きくない場合などは、メンバーと同じような仕事をするプレーヤーとして動かないといけない場合などもあります。 多くのタスクは「

          ボールを持ち過ぎないように

          仕事をするプロとして技術系ブログから学んだこと

          English version. 今回のブログは自分が本格的にプログラミングを始めた頃に技術系ブログから学んだことについてまとめたいと思います。きっかけはこのポッドキャストでMCのAdam Gordon Bellが放ったこちらの一言です。 (ちなみに、このポッドキャストの回はとても面白かったので、是非聞いてみてください。) 自分も確かに技術系ブログを多く読んでおり、同じことを感じています。自分の場合は100件以上のブログを購読しており、毎日チェックしています(100件以

          仕事をするプロとして技術系ブログから学んだこと

          コードをモジュールに分割する

          English version. 先日、大学で一緒にコンピュータ科学を学んでいた友達と話す機会がありました。彼は今、大学で情報科学の准教授をしていて、仕事の一環でプログラミングを教えています。 彼も自分もエンジニアリングが好きであり、またエンジニアを育てる立場にあるので、自然と会話はプログラミング教育についてになりました。 自分の今までの経験を振り返ると世の中には周りのコードを真似して、エラーが出たら調べながら直していくのでなんとかなっているエンジニアがいると思っています

          コードをモジュールに分割する

          プログラミングの基本にあるもの

          English version 以前、ブログで書いたように、プログラミングスキルはどう身に付いていくものなのか、身につけていくべきものなのかに興味があります。プログラミングはスキルとして難しくて、プログラミング言語、フレームワーク、コンピューターの仕組み、ネットワークの仕組みなどいろいろな知識が必要です。成果物が「動く」「動かない」の二値ですし、コードにちょっとでもミスが、コンパイラに怒られたり、クラッシュしてしまいます。 Fizz Buzz問題難しいとは言いつつも、どこ

          プログラミングの基本にあるもの

          新しいもの

          English version. ソフトウェア開発をする際に、どのソフトウェア、プログラミング言語、フレームワーク、ライブラリを使うかを決める(いわゆる技術選定)って難しいですよね。使おうとしているものが「必要なことをやってくれるか?」とか「コミュニティがちゃんとあるか?」とか「来年もメンテナンスされチエルか?」など考えることがたくさんあります。 そんな難しい問題に対して、今も「新しいもの」に飛びつくエンジニアをよく見かけます。自分もやってしまったことがありますし、読者の

          新しいもの

          腐っていくとき

          English version. いろいろなレポジトリでコードを書いていて、なんか心地よくない、気持ち悪いと思ったことはないでしょうか?自分もいくつかそういうレポジトリを見てきましたし、自分でそういう場を作ってしまったこともあるな、と思っています。 一般的にその感じを「腐っている」と表現されることがあり、今回のブログでは自分の体験を織り交ぜながら、その腐っていく過程、その小さな症状、そしてその対処法について書いていきたいと思います。 割れ窓理論もちろん最初から腐っている

          腐っていくとき

          ソースコードは命令か、メッセージか?

          English version. エンジニアとして働く中で、いろいろなコーディングスタイルなどを見てきていますが、大きく異なる2つのタイプがあるように思います。1つ目のタイプは、ソースコードをコンピュータへの命令と捉えて書かれており、2つ目のタイプはソースコードをコンピュータがやるべきことをまとめたメッセージのように捉えて書いているように感じます。 今回記事では例を紹介しつつ、2つの違いについて考察したいと思います。 タイプ1:ソースコードは命令1つ目のタイプでは、ソー

          ソースコードは命令か、メッセージか?

          良いマネジメントは見ることと気遣うことから

          English version. 自分はかれこれ6〜7年間マネジメントを経験しています。チームの大きさは2〜10人ほどですが、メンバーの経験や雇用形態(正社員、契約社員など)などは様々です。その中でもいろんな経験と失敗をしてきました。書籍を読むことで学んだこともありますし、自分の上司やメンターから学んだことなど様々です。 今回はよくある「マネジメントとは」という記事を書くつもりではなく(というか、そんなな大層なものは書ける気がしません)、代わりに自分が良いマネジメントをす

          良いマネジメントは見ることと気遣うことから

          実際にタイヤが道路に触れる場所

          English version. この言葉は、私のお気に入りのポッドキャスト、Developing Leadership エピソード#2からの引用です。Jason Warner(元GitHub CTO)は: という表現を使って、実際に仕事が進むのはエンジニア組織であることを言っています。IT企業には当てはまることは直感的にもすぐ分かりますが、近年より多くの企業がソフトウェアに依存するようになるにつれ、他の企業にも当てはまるようになってきています。会議などで議論を重ねてもエ

          実際にタイヤが道路に触れる場所