この記事は pyspa Advent Calendar 2024 の14日目の記事です。この記事で言いたいことを先にまとめると以下になります。 日本の技術系アドベントカレンダー文化は独自の進化を遂げている エンジニアに限らない広がりも見せている 良い文化だし長く続いて欲しいと思う 元の文化への敬意を忘れてはいけない 宗教色があるものだし、少なくともアドベント期間外に拡張しない方が良いと私は思う 長くこの文化を楽しむためにも 技術系以外のトピックでもアドベントカレンダーが作られることがありますが、この記事では便宜上それらも含めて技術系アドベントカレンダーと呼称します。 技術系アドベントカレンダー 日本の主に技術系のインターネット界隈では毎年12月になると、技術系アドベントカレンダーというムーブメントが発生します。ある技術トピックに対して、12月1日から25日まで複数人が持ち回りでブログを書く
これは VTuber・Vクリエイター Advent Calendar 2024 - Adventar の19日目の記事です。大遅刻。 Channel 78.9 という YouTube チャンネルでたまーに長時間の配信をやっている。内容はプログラミングとかコンピュータサイエンスとか、そういう感じだ。 www.youtube.com 配信頻度のごく低い私が、何を楽しみにして活動をやっているのか、ということについて書こうと思う。普段、自分のモチベーションや活動の裏側については動画や配信内ではあまり言及しないように、いわゆる舞台裏を明かさないようにしている。そうしている理由もこの記事の内容とちょっと関係があるのだけれど、いい機会だと思って筆を執ってみる。 「なぜベストを尽くしたのか」 「なぜベストを尽くしたのか」とは、ニコニコ動画で（やや）ポピュラーなタグの一つである。その意味について、ニコニコ大
マルチプロダクト戦略を掲げてプロダクトを急速に増やし続けている SmartHR のフロントエンド領域について、2018年から SmartHR に参加しているフロントエンドエンジニアの nabeliwo と技術顧問の koba04 が、これまでの振り返りと今後の展望を話しました。 SmartHR のフロントエンドでどんな技術が使われてきてどんな課題と向き合ってきたのか、そして今現在取り組んでいる課題や SmartHR ではどんなフロントエンドエンジニアが求められるのかなど、幅広いテーマが出てきました。 この記事ではその模様をお届けします。 目次 フロントエンドの Rails からの脱却とフロントエンド領域の確立 SmartHR UI の誕生 プロダクトの急増 複雑化する技術課題 テストの整備とロジック共通化の取り組み Next.js の導入 新たな技術的挑戦 フロントエンドミーティングの見直
登壇中にうっかりSlackの通知が出ちゃうみたいなことを避けたいですよね。うっかりを防ぐ対策が集まるスクラップです。
私がWeb業界に入ったのは、ハッカーに対する憧れからです。その原体験を大事にしたいという気持ちを今でも強く持っています。 もう20年近く前になりますが、Web2.0の時代、私は傍観者でした。世界ではGoogleを筆頭として、日本でも、はてな社などが、エンジニアドリブンで個性的なサービスを生み出していました。他にもmiyagawaさんなど、個人で世界的に使われるようなOSSを開発している人もいました。書籍「ハッカーと画家」で描かれるような、ハッカーが個人技で大企業を出し抜く痛快さがありました。 そのように、WebサービスにせよOSSにせよ、同年代のハッカーが自分の技術でイノベーションを起こし、世の中に影響を及ぼしていることに羨望の眼差しを向けていたのです。 サブカル的な空気感も好ましく思っていました。西海岸のコンピュータ文化はヒッピーカルチャーの影響を受けていたのは間違いないでしょう。当時の
✍️ 仮メモ。需要があったらちゃんと書く 基本方針 RSSは購読数を気にせずに購読していく Watchを長く続けていくと、更新の方が止まるので、増やしても購読数は一定になる 情報の更新は一箇所に集まるようにする 自分の場合はRSS メールマガジンなどもRSSにまとめる メールの受信トレイを空にするInbox Zeroを始めた | Web Scratch 後で読む も自動でRSSにまとまるようにする 一箇所に集約することで色々と楽になる 追っていて、新しい追い方を見つけたら増やす まとめている場所とかがグルーピングできたら、それをグループ化して機械的に扱えるようにRSSなどに変換する おそらく、量を扱う場合はpushではなくpullにすることでスケールする。 一方で、質を扱う場合は逆のアプローチをとる。 コメントで追い方が増える GitHubのリリースノートの追い方 GitHubでリリースが
なぜ？ 「Suica」がサーバ型に移行する理由 25年近く稼働する“安全神話”の象徴に何が（1/3 ページ） 4月4日昼頃、一部店舗でSuicaを含む交通系ICカードなどFeliCa系電子マネーが利用できなくなる障害が報告された。筆者はちょうどその時間帯にイオン系の「まいばすけっと」で買い物をしていたが、「この時間、交通系ICカードが利用できません」との告知でレジ待ち行列が混乱している様子が見受けられた。このほか、自販機での電子マネー決済ができないという報告も多数散見され、それなりの影響が出ていた印象だ。 同日中にJR東日本メカトロニクスから「クラウド型マルチ電子マネー決済システムにおける不具合発生につきまして」というプレスリリースが出されており、処理センターのハードウェア障害であることが報告された。確認した範囲で、同社が日本カードネットワークと共同運営している「J-Mups」における障害
日本を代表するブログサービスをはじめ、近年ではサーバ監視サービスMackerelでも知られる株式会社はてな。日本におけるWeb開発の黎明期から現在に至るまで、新旧さまざまな技術スタックが混在する環境で、CTOであるmotemenさんこと大坪弘尚さんはどのような心構えで技術選択に挑んでいるのか。初代はてなCTOでもある株式会社一休CTOの伊藤直也さんが聞き出します。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務めた株式会社はてなでは「はてなブックマーク」などの開発を主導。グリー株式会社では統括部長としてSNSを担当した。2016年4月、一休に入社し執行役員CTOに就任。 ・大坪 弘尚さん / 株式会社はてな CTO 2008年、東京大学大学院情報理工学系研究科を中退後、アプリケーションエンジニアとして新
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の後編では、現在とこれからのIT業界におけるプログラミング言語のトレンド、具体的にはRustを始めとする静的型付き言語への視座から、 ソフトウェアエンジニアとして新しい技術を学び続けるうえでの態度について語り合います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務めた株式会社はてなでは「はてなブックマーク
発表資料作り、全体的な流れは 1 週間ぐらいかけて構想して、半日使って 15,000 字ほど書いて (コード片含む)、半日使ってスライドに起こす(結果として 6000 字ぐらい使う)、って感じですね。貯めた文字列を組み合わせている最中に構想とは別のストーリーが降ってくることも多い。— Takafumi ONAKA (@onk) July 3, 2018 このツイートの「文字を組み合わせる」のところについて、もうちょっと掘り下げてみる。*1 この記事は はてなエンジニア Advent Calendar 2022 の1月2日の記事です。昨日は id:stefafafan で 『UNIXという考え方―その設計思想と哲学』を読んだ - stefafafan の fa は3つです でした。 3 つのポイント 知っていること 7 割、聞いたことがあること 2 割、知らないこと 1 割 引用しやすいワー
それはベンツなんよ 総括 今年はコードをよく読むようにした。 技術的にはひき続きPaaSやクロスプラットフォームの動向に注目した。 デファクトの移り変わりを感じるので来年以降はGoやGraphQLに手を出していきたい。 去年のエントリ: 2021年に作ったモノや技術をふりかえる 今年やったこと コード読み 去年はコードを書くことに注力していたので今年は一転コードを読んでいた。 プログラム雑談ポッドキャストを聞いていて「コード読み」っていう言葉がよく出てくるので聞きながらそういえば自分もこの分野が好きだなと思い出したので意識してやることにした。 丁度、最新技術のトレンドだけ俯瞰しているのに学びを感じなくなってきたのでより潜りたい気持ちがあったのでそれを満せたと思う。 IntelliJ IDEAで全言語のプログラミング環境が楽に揃っているのが心強い（Samuraismさんありがとう）。 読んだ
Ubie では、創業当初から Server-Side Kotlin を推進してきましたが、全社的な技術選定を再度行い、これからは Go と Node.js を中心とすることにしました。 本記事では、Go と Node.js を選定した理由や、それを普及させる取り組み、そして選定の流れを紹介します。 経緯 これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。 まず、事業成長に伴って運用の重要性が増しています。人材が潤沢とは言えないスタートアップにおいて、様々な技術スタックを安定運用することはコストが高すぎると感じています
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
Zennのパブリケーション（Publication）とは、Zenn上に複数人で管理できるメディアを作ることができる機能です。企業や技術コミュニティなどの単位でPublicationを作ることで、複数人で一つの場所に特定のテーマについての記事を投稿してくことができます。 Publicationのトップページ 開設されたPublicationのロゴやカバー画像、プロフィール文、リンクなどは自由にカスタマイズでき、メンバーの情報発信により企業やコミュニティのブランディングをしていくことが可能になります。 Publicationに投稿された記事 実際に開設されたZennの開発チームのPublicationをこちらから確認できます。 ZennがPublicationで解決したい課題 テックブログに投稿する記事を著者本人のものに 例えば企業のテックブログでは、多くの企業が更新を続けることに苦労している
チームで何かアプリケーションを作る時にどんなプログラミング言語を使ってどのフレームワークでどういう技術を使って作ろうか？ と話し合いが行われることがある。この意思決定プロセスは技術選定とか呼ばれている。 そこに出てくるフレームワーク、に限らずソフトウェア技術・ツールの選択基準に大きく関わる「どのぐらいこの技術は使われているのか、主流なのか、シェアがあるのか・今後増えていくのか」という要素がある。 そこでは「たくさん使われている・寡占的な技術ほど良い」という価値観が広く共有されている(業界によって枯れた技術にフォーカスしたり、投資対象としての新技術の範囲を限定したりするから単純にユーザー数というわけでもない)。 その背景には 開発者の数を増やして規模を拡大する 開発者人材の流動性が高い 変化を予測しづらいエコシステムの性質 というものがあると思う。 たくさん採用してすぐやめちゃうのでみんなが
そろそろ更新も止まってきたし、一旦シーズン1終了的な感じで終わりにしようか、 ついでに振り返りでもやったらいいんじゃない？ と言ったら、じゃあ最初書いてよ、と言われたので書いてみます。 自分としては更新がだんだんとされなくなって自然消滅、みたいなのよりは、 区切りをつけたいと思っていたので、 ひとまずシーズン1はこれにて終了、という事になりました。 別段シーズン2の事を考えて言った事でも無いので、今後の事とかは何も決まってません。 自分個人としてはそのうちまた再開してもいいかなぁ、とは思っています。 外から見ると凄くまともに出来ているように見えるこのMessage Passingだけれど、中はびっくりするほど何も決まってない感じで運営されています。 始まった時には書いている自分もこれが何なのかは良く分からず、なんか技術的な事を書いて回してみよう、みたいな程度でした。 プラットフォームとかも
技術選定を行う前にまず、どのような開発組織にしたいのか、どのように事業を進めていきたいのか、そこを整理しないと上手くいかない。 そんなことを最近考えていたので、ブログに書いておく。自分は書くことで思考を整理していくので。 この記事では、「技術選定」そのものについて書いていく。 そのため、個別のライブラリの良し悪しを判断する手法などについては扱わない。もっと抽象度の高い、どのような考え方や態度で技術選定に臨むべきか、というようなことを書いていく。 また、作りたいものを作れるか、仕様を満たせるか、セキュリティ上の問題はないか、などの当然の前提は省く。 そういった「最低条件」を満たした技術が複数あったときにどうやって選ぶのか、という意味での「技術選定」を扱う。 お互いの「納得感」のためにもまずは軸を明確にする 技術選定について考えたり誰かと議論したりする際には、「自分たちは今、どういう観点を基準
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く