くりたしげたか（eR）🌰ニコニコ代表の人 @sigekun 栗田 穣崇 Shigetaka Kurita ぼかれびゅ部長/ニコニコ代表/合成音声栗田まろんの中の人 /ドワンゴ取締役COO/カスタムキャスト取締役/個人垢のためニコニコへのご意見ご要望は運営窓口担当@nico_nico_talk まで🙇♂️ 開発に携わった絵文字がMoMAとM＋に収蔵✨ イラスト：アルセチカ nicovideo.jp/user/9003560 くりたしげたか（eR）🌰ニコニコ代表の人 @sigekun Twitterのタイムラインはユーザーから見ると「ツイート並べてるだけでしょ？」みたいに簡単なサービスに見えるけど、エンジニア視点で見ると、作ってと言われたら断りたいほどめんどくさいしろもの 2023-07-04 11:55:46
# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.hatenablog.com/entry/2020/08/14/101657 # 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition # 判断と決断の違いと決断のコツ https://soudai.hatenablog.com/entry/2022/01/04/151923 # Worse Is Better -
けいとら @LightTiger2505 ギークになりたいプログラマ。主にVimとGoをいじいじしている。主成分はコーヒーと鶏むね肉。定期的にサウナによるメンテナンスが必要。 けいとら @LightTiger2505 引っ越しするので、物件の内見行ってきたんですけど。どの物件もめちゃ遅無料インターネットをご提供しているおかげで、光ファイバーが引けない人権侵害物件だらけで、世の中の不条理に打ちひしがれている。 不動産屋さんは十分早いですっておっしゃっているんですが、30Mbpsが早いわけない。 2023-10-09 12:23:46
めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか？」「なぜこれをやってるんだっけ？」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状
【追記 2023/06/26】 テックリードに求める役割と適切なチームサイズについて - pospomeのプログラミング日記
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
百番煎じのNTT退職エントリ
2023年6月末をもって、約7年間勤めたNTT研究所を退職することになりました。7月からは外資系IT企業でデータサイエンティストとして働く予定です。これまでは研究員として、ネットワーク運用を支援するための機械学習について研究してきました。これからはエンジニアリングやデータ分析を生業にしていきます。 この記事は、僕がなぜNTTをやめたのかをまとめた、いわゆるNTT退職エントリというやつです。NTT退職エントリという言葉が定着したのは、以下のkumagiさんの伝説の記事がきっかけでしょう。 この記事が公開されたのが４，５年前でしょうか。公開以降、NTT退職エントリというものがあちこちで書かれたので何番煎じなのかも不明なのですが、自分自身の記録として残しておこうと思います。 NTT退職エントリを読んでいる方の中には、NTTへの入社を検討している人もいるでしょう。NTTの一般的なメリットとデメリッ
複数の言語で同じWebサービスを実装して技術特性の違いを見てみた - Hatena Developer Blog
開発合宿運営チームの id:yutailang0119 と id:maku693 です。はてなでは四半期に一度、技術グループ主導で開発合宿を開催しています（過去の合宿の様子は「開発合宿」カテゴリーにまとまっています）。 2023年4月に実施した開発合宿では、参加者が複数のチームに分かれ、それぞれ異なるプログラミング言語で同じお題のWebサービスを開発しました。言語ごとの特性を比較し、今後の技術選定に生かす取り組みです。 この記事ではその開催レポートをお届けします。 開発言語の特性を理解したい さまざまな技術要素を2日で実装できるお題に 参加チームやコミュニケーションでの工夫 順調に開発が進んだ合宿当日 技術勉強会で「成果物を見る会」を実施 開発合宿を終えて プログラミング言語ごとの使用ライブラリ TypeScript Go Ruby Scala 開発言語の特性を理解したい はてなではたくさ
「とほほのWWW入門」管理人の杜甫々氏が、これまでの経歴と、「とほほのWWW入門」執筆時に気をつけていること、自身の趣味について話しました。全2回。 「とほほのWWW入門」管理人 杜甫々氏 杜甫々氏（以下、杜甫々）：どうも杜甫々です。「とほほのWWW入門」というやつを作っています。こういうところに出ることはあまりなくて、2022年の岡山のオープンセミナーも録画でやっていたので、こんなにたくさんの人の前でしゃべるのは初めてだったりします。 まずちょっと、おじさんの紹介をやっていきます。「とほほのWWW入門」の管理人です。1996年から始めたので、もう27年目に突入ですね。ハンドルネームは杜甫々です。途中で漢字を当てはめてみました。本名は違いますけどね。 広島生まれの広島在住です。もちろんカープファンです。2023年の観戦成績は6勝1敗で、けっこう良かったんじゃないかなと思っています。 次にイ
「フリーランスエンジニアになりたいけど、スキル不足だったらどうなっちゃうんだろう」 こんな悩みはないだろうか？ 筆者はフリーランスエンジニアとして２回活動した経験がある。１回目はエンジニアを始めて３年目の時だ。そして２回目はエンジニアを始めて７年目の時だ。この２回の経験からスキルの有無によって、フリーランスエンジニアとしての活動が大きく異なることを肌身を持って実感した。 具体的には、スキル不足な状態でフリーランスになると短期的にも長期的にも厳しいということだ。逆に、スキルが十分にある状態であればフリーランスとして活動することのメリットはとても大きい。 そこで、この記事ではスキルが足りない状態で背伸びをしてフリーランスエンジニアになるとどうなるかを実体験をベースに解説する。 この記事が筆者のように辛いフリーランス活動を経験する人を減らすことに貢献できたら光栄だ。 ①すぐに契約を切られるストレ
エンジニアは勉強し続けないといけない？
ゆいゆい @yuiyui12322 これ系の話いつも思うけど、勉強が必須なんじゃなくて、必要なときに必要な技術が必要なんだよね。 それを習得するために勉強が必要なわけで。 この関係をわかってないと、勉強だけしてる無能エンジニアができあがる。仕事で必要な技術持ってるなら勉強いらないよ。 twitter.com/axgPom7dc4gDGX… 2023-07-28 10:14:54 サカモト@エンジニアキャリア論 @sakamoto_582 エンジニアは一生勉強し続けないといけませんか？ サカモトを例に話そう。これが年収1000円超えのエンジニア、プライベートでの学習に関するスタンスです 1. 休日勉強してる？ 最近だとLeetCodeの問題を解いてるけど別に好きではない、SNSアカウントのアウトプットになると思ってるから解いてる。 twitter.com/i/web/status/1… 20
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会
はじめに 今回は私が3年間で読んだ技術書をひたすら紹介します。 私は2021年4月に新卒でSIerに就職し、2024年4月でエンジニア4年目となりました。 そんな私の入社時のスキル感はどうだったかというと... 非情報系学部卒の理系 学部4年生の時に研究室で少しPythonを触ったことがある程度 HTTP?なにそれ？ でした。 こんな感じでほぼゼロからのスタートでしたが、3年間でどのくらいのスキル感になったかというと、ざっくりと 基本的に一人称で開発業務ができる 小規模のシステム開発なら技術選定やアーキテクチャの検討も可能 某(若手向け)技術コンテストで入賞経験あり OSSコントリビューション経験あり IT関連の資格7つ取得 くらいには成長することができました。 これから紹介する技術書を読むだけでこのくらいのスキル感になれますという話ではなく、当然日々の業務であったり、その他のインプット/
by Hillel Steinberg ハイテク企業やベンチャー企業のトップが、「これからの若者はプログラミングを身につけるべき」とアドバイスするのを見聞きしたことがある人は多いはず。こうした潮流とは裏腹に、NVIDIAのジェンスン・フアンCEOが「プログラミングはもはや不可欠なスキルではない」と提唱しました。 NVIDIA CEO: Every Country Needs Sovereign AI | NVIDIA Blog https://blogs.nvidia.com/blog/world-governments-summit/ Jensen Huang says kids shouldn't learn to code — they should leave it up to AI | Tom's Hardware https://www.tomshardware.com/tec
本稿の趣旨は米国連邦政府のクラウド推進戦略、いわゆる「Cloud First」から始まる一連の政策が辿った経緯を概観することである。米国のクラウド戦略は、掛け声こそ勇ましかったものの、あまりうまくいかなかった。これは筆者の主観ではなく、連邦政府自身がそれを認めるレポートを出している。あとで具体的に見ていこうと思う。 本邦においてもガバメントクラウドが本格的に動き出している。さくらインターネットが政府公認のベンダーとして認証を受けたことが話題になったのはつい最近のことだ。本邦のクラウド戦略もかなり米国のそれを参考にしており、そのまま進むと同じ轍を踏む可能性もなきにしもあらずである（実際には米国と日本では政府の置かれている状況がかなり違うので、一概に米国と同じ道筋を辿るとは言い切れないのだが）。しかし、世界で最も積極的にクラウドを採用した政府がどのような点で成功し、どのような点で苦しんできたか
9/7 タイトルを修正&一部加筆しました。 非エンジニアでもできる！ウェブ地図サイトの作り方 → 非エンジニアの自分がウェブ地図サイトを公開するまで こんな風にグリグリ動かせるウェブ地図サイト、作ってみたいけどハードルが高いなぁ…という方もいらっしゃるのではないでしょうか。 実際、自分もサイトを作るまではそう思っていました。 しかし意外と簡単に、オープンソースのソフトのみで作れてしまうんです！ （サーバ代や取得するのであればドメイン代等はかかりますが…） 非エンジニアのデザイナーの自分ですがサイト公開までできたのでやり方を共有します！ ※自分のスキルとしては関してはgithubもVScodeも使えない、CSSとhtmlぐらいならツギハギでなんとか…(10年前ぐらいの知識)というレベルなので、特に後半のサーバ周りに関してもっと楽なやり方があるかもしれません。 QGISで地図を作る 一番の肝は
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
ネットがあるでしょ？ わたしもそう思っていた。 ITスキルに限らず、新しい技術や分野を学ぶとき、最初にすることは検索だ。ネットで紹介されている記事やノウハウを読むことで、どんなものか把握できる。無料で最新の情報が手軽に手に入る。お金をかけずに学習できるメリットは大きい。 一方で、ネットで検索するためには適切なキーワードを入れる必要がある。 知りたいことがピンポイントで言語化できるなら、かなり便利だろう。だが、そもそもどんな用語を入れたらよいのか、その言葉すら分からない段階では、ネットを使いこなすのは難しい。自分に何が足りないのかは、自分には見えにくい。知らない知識は検索すらできない。 いわゆる探求のパラドクスだ。知らないことが何であるのか分からないのなら、「それ」を学ぶことすらできない。行き当たりばったりに学んで、「それ」に行き当たったとしても、「それ」が何であるか分からないのだから、行き
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
全エンジニアが知っておくべきGithubレポジトリTop28【2023最新版】 - Qiita
この記事はNuco Advent Calendar 2023の18日目の記事です。 はじめに 本記事ではGithubレポジトリTop28を紹介します！ Githubレポジトリは日々の業務や学習に役立てることが可能です。必要な機能や学習教材は、無料で利用出来る高機能なものがあるのなら積極的に利用して役立てるべきです。 以下の内容に分けて合計28個のGithubレポジトリを紹介します！ 開発用Githubレポジトリ 学習用Githubレポジトリ QOL高めのエンジニアとして日常を過ごしたい方は参考にしてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。
たまにSNSで論争になるので、意見を言っておこう。 日進月歩のIT業界でお勉強するべきかって話。 そりゃ、しないと置いて行かれるでしょうね。特にソフトウェア周りって、気を抜いているとどんどんバージョンアップして、操作方法も変わる。基本的なことさえ押さえていれば、あとは便利になっていくだけだから新しく勉強することなんてないよね勢がいるのもわかるが、それでも時間的に限界はある。7.0と8.0は大きな違いが感じられなくても、7.0と15.0はもう全然別のソフトウェアになっている。 どんなソフトウェアも、情報処理技術者試験で出てくるような基本から成り立っている。その上に応用としての技術があるので、基本をしっかり身に付けていれば、ある程度の技術の変化にはついていける。それは間違いない。 問題は、この基本の部分をどの程度習熟しているか。それこそ年齢が若い時に、仕事「以外」の時間も使って学ぶことをお勧め
認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介
認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介 この記事の目的 ここ数年で、ソフトウェア開発やプログラミングの文脈で、「認知負荷」 および 「認知負荷理論」 という用語をよく見聞きするようになりました。私が今思い出せるだけでも、以下のような書籍や Podcast で重要なキーワードとして取り上げられています。 A Philosophy of Software Design, 2nd Edition チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ fukabori.fm 102. A Philosophy of Software Design (3/3) w/ twada この「認知負荷」ですが、少なくとも近年見聞
勉強できない人は他の仕事やれって言ってるけど、こいつら無意識に他の職業の人は勉強してないと見下してるんやろうな。 本当に視野が狭いと思う。 コイツラはプログラミングやらなんやらの知識を身につけることしか勉強と考えてない (あえて技術とは言わない)。 勉強だって色々なものがあるわ。 英語や資格の勉強はもちろん勉強だし、経理であれば会計分野の法律改正、医療であれば新しい治療•診断•薬剤、接客業やコールセンターであれば新商品の知識。 企画やマーケティングであればここ数年サブスクビジネスの書籍読んでる人も多いだろうし、自己啓発で本読んでるのだってそれも勉強。 業界の法律やルールなんかも勉強してる人は多いやろ。 勉強会だって社内や業界でやってる。 そして新しい機器、システム、オペレーションなんかはどんな職種でもある。 こういうのはさ、ITエンジニアが「我々は勉強してるんだ！」なんて主張する以前に他の
エンジニアの間では発売から瞬く間に広まった本書ですが、まだ読んでない方々向けに本記事を書いてみました。要約なので、ここは重要だなと感じたポイントに絞って本記事に記載します✏️ 概要 まず結論からいうと、仕事の進めかたや捉え方という点でとても学びのある良書です。すでに多くのエンジニアには知れ渡っていますが、もっともっと知れ渡って欲しい本です。 内容としては、著者の牛尾さんがアメリカのMicrosoft社（Azure開発）で得た経験がそのままに書かれています。最初はアメリカのエンジニアに劣等感を感じていたようですが、その理由を言語化して、実際にどうすれば彼らと肩を並べるエンジニアになれるかが書かれています。 また全体的にアメリカのエンジニア思想を爆推ししているので、こっち系の思想が好きな人は一瞬でハマると思います。私もどちらかと言えば圧倒的にこっちのタイプですが、読むときには偏らないように中立
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
この記事は一休.com Advent Calendar 2023 8日目の記事です。 2023-09-25に入社して2か月半が経ったので、既存のWebサービスの開発にソフトウェアエンジニアとして参加するにあたって役立ったことを書いておく。 『Webサービスのソフトウェアエンジニアとしての転職活動で役立ったこと』の続編といえるかもしれない。 前提 観点 どのようなサービスかを調べる どのようにデータを保持するかを調べる どのようなコードかを調べる 「未知の未知」をできるだけ早く減らす チームの開発体制に興味を持つ 所感 前提 レストラン予約のサービスの開発に参加した 歴史が長い（2006〜） Webアプリケーションを開発する 技術スタックは転職前後で完全に変わった 前: Rails, PHP, Nuxt, MySQLなど7年 後: Rust, Next.js, Python, Microso
22年前からFirefoxブラウザに存在したバグ、23歳の初心者プログラマーが修正 | テクノエッジ TechnoEdge
ガジェット全般、サイエンス、宇宙、音楽、モータースポーツetc... 電気・ネットワーク技術者。実績媒体Engadget日本版, Autoblog日本版, Forbes JAPAN他 デスクトップ版のFirefoxブラウザーに20年以上存在していたバグが先月、23歳のプログラミング初心者によって修正されました。 2002年、MacでMozilla browser（Firefoxの当時の名称）を使用していたアダム・プライス氏は、ツールチップの表示の問題に悩まされていました。このバグは、Mozillaツールバーのアイコンにマウスカーソルをポイントして表示されるツールチップ（説明書き）が、Commandキー(WindowsではAltキー)+Tabキーでウィンドウのフォーカスをほかのアプリに移したあとも表示され続けてしまうというもの。 この状態になってしまった場合、ツールチップを消すには再びFir
「それをやると怒られるからできません」無駄を誰も止めない、社員は子供扱い……“生産性を爆下げ”する日本企業の特徴 | 文春オンライン
澤 そうですよね、今日は楽しみにしていました。我々がどういうつながりか分からない視聴者も多いと思うので、まずお互いに“他己紹介”しましょうか？ 牛尾 いいですね！ 澤 じゃあ、僕からいきますね。牛尾剛さんは、もともとはマイクロソフトの日本法人のほうで働いていて、僕の同僚として席を並べて働く間柄でした。所属部署は違ったのですが、お互いテック系の人間で様々なイベントでの登壇が義務付けられていて、僕はビジネス中心の話をする一方で、牛尾さんは開発者の視点から情報発信をする役割。その頃の牛尾さんは、主にソフトウェア開発の手法を人に伝える仕事をしていたんですね。 で、イベントの時にプレゼンテーションのレビューをして欲しいと、よく僕に依頼をしてくださって、一緒に完成度を上げるお手伝いをしていたんです。ある時なんて、イベント会場のホテルに前日から泊まって、夜中の1時過ぎまでレビューをしたこともありましたね
JSON Canvas
An open file format for infinite canvas data. Infinite canvas tools are a way to view and organize information spatially, like a digital whiteboard. Infinite canvases encourage freedom and exploration, and have become a popular interface pattern across many apps. The JSON Canvas format was created to provide longevity, readability, interoperability, and extensibility to data created with infinite
日本CTO協会が主催の「Developer eXperience Day 2023」は、“開発者体験” をテーマに、その知見・経験の共有とそれに関わる方々のコミュニケーションを目的としたカンファレンスです。ここで登壇したのは、株式会社カウシェの柴田芳樹氏。45年の歴史から振り返ったソフトウェア開発とキャリアの変遷について発表しました。全3回。3回目は、柴田氏が影響を受けた出来事と、技術教育への取り組みについて。 米国駐在・Javaの登場・日本オラクルの社長の言葉…柴田氏が影響を受けた出来事 柴田芳樹氏：影響を受けた出来事について、ちょっと簡単に話をしていきます。 まず、初めてアメリカに駐在する時の送別会で、駐在経験のある先輩から、アメリカに行った時は「与えられた開発タスクをこなすと、さらに難易度の高い開発タスクが与えられるから注意しろ」と言われたんですね。 最初はピンと来なかったんですけど
Theadsの提供地域などについてはMetaからまだ発表がないが、英Guardianによると、EU圏では個人データ使用に関する規制上の不確実性を理由にサービスを開始しない予定という。 MetaはEUの一般データ保護規則（GDPR）に違反したとして、たびたび罰金を科されている。 【UPDATE】さらに前倒しされ、午前7時40分ごろには登録可能になった。 関連記事 Twitter対抗「Threads」、日本でもダウンロード始まる ただし使えるのは6日夜から 7月5日午後11時ごろから、米Metaの新アプリ「Threads」のダウンロードが始まった。同アプリは、Instagramをベースとしたコミュニケーションアプリで、Twitter対抗として注目されている。 Meta、Twitter競合の「Threads」の“予約注文”ページをApp Storeで公開 Twitterで混乱が続く中、Metaが
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
河野太郎氏が激怒。トラブル続出の「富士通」コンビニ交付システムが炙り出したIT後進国ニッポンの致命的な問題点 - まぐまぐニュース！
マイナンバーカードのメリットのひとつとして総務省が掲げる、コンビニでの各種証明書の取得。しかし今年3月以降、別人の証明書が発行されるトラブルが相次ぎ、サービスが一時停止に追い込まれる事態となってしまいました。何がこのような問題を引き起こしてしまったのでしょうか。今回のメルマガ『週刊 Life is beautiful』ではWindows95を設計した日本人として知られる中島聡さんが、「コンビニ交付システム」の開発運営を典型的なITゼネコンの手に委ねた事が主因と断言。さらに同様の問題を回避するため国が取るべき「ソフトウェア調達法」の具体案を提示しています。 プロフィール：中島聡（なかじま・さとし） ブロガー／起業家／ソフトウェア・エンジニア、工学修士（早稲田大学）／MBA（ワシントン大学）。NTT通信研究所／マイクロソフト日本法人／マイクロソフト本社勤務後、ソフトウェアベンチャーUIEvol
はじめに 研究開発第二部リードセキュリティエンジニアの一瀬です。セキュリティエンジニア同士の会話では、「"シサ"が最近またレポート出していて…」とか「"アイピーエー"から注意喚起出てたね」といった、初学者には謎の単語がたくさん出てきます。本記事では、そういった会話に出てくる単語のうち、国内外のセキュリティ関連の主な組織についてまとめました。セキュリティに興味があれば、ここに挙げた組織と、その組織が関わる政策や活動について、事前に抑えておいて損はありません。これからセキュリティを学ぼうという方の参考になれば幸いです。 なお、記載した情報はすべて執筆時点 (2023 年 6 月) のものです。 【2023/06/30 追記】NISC および ENISA の日本語名称を修正、CISA の読み方について修正・追記、NCSC について追記しました。 はじめに 中央省庁 内閣サイバーセキュリティセンタ
2024/02/10に行われたYAPC::Hiroshima 2024で発表した内容です。 ■リンク LayerXにおけるEM実践例のご紹介 https://tech.layerx.co.jp/entry/2023/12/20/115724 カジュアル面談 https://jobs.layerx.co.jp/7b31f370acc0411994174700fe212287 LayerX Casual Night（2024/02/13, 2024/02/26） https://jobs.layerx.co.jp/casual-night EMゆるミートアップ vol.6（2024/03/01@ビットキー） https://em-yuru-meetup.connpass.com/event/308552/ ■参考・出典 アンドリュー・S・グローブ「HIGH OUTPUT MANAGEMENT」
少子化に伴い人手不足が業界を問わずに叫ばれています。しかしまとまった数の正社員希望者がいるにも関わらず、企業からほぼ見向きもされていないのが就職氷河期世代です。就職氷河期世代は1975年から1985年に産まれた人が該当すると言われています。正社員ポジションの募集に恵まれなかった時期です。
みなさんSREしてますか？ サービスなどの品質を維持していくために切っても切り離せないSREですが、 日本でもSREという言葉が定着しつつあるかと思います。 このSREについて書いていきたいと思います。 SRE NextのCFP忘れてたのでその代わりに・・ SREってインフラですよね？ 非常によくあるケース、というか多分ほとんどがこうなっていると思います。 もちろん会社としてインフラのことを指しても問題はありませんが、 SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで さらに良い活動に繋がることが多いと思います。 なんのこっちゃ、という方も多いかもしれません。 SREはエラーバジェットなどの話が必ず出てきますので、 モニタリングや監視などが必ずセットにはなっていきます。 ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、 というのが定着している場
サイバーエージェントのGitHub CopilotのAnalyticsデータを公開！利用開始から約3ヶ月でエンジニアの生産性は向上したのか？ | CyberAgent Developers Blog
サイバーエージェントのGitHub CopilotのAnalyticsデータを公開！利用開始から約3ヶ月でエンジニアの生産性は向上したのか？ CTO統括室の黒崎(@kuro_m88)です。サイバーエージェントでは2023年4月下旬より、GitHub Copilotの導入を開始しました。 「実際のところどうなの？」という情報がまだまだ少ないと思われるので、本記事では導入から約3ヶ月が経過した現在の利用状況を公開します。 GitHub Copilotの利用状況 2023年7月現在、サイバーエージェントでは500名以上のエンジニアがGitHub Copilotを利用しています。 追記 7/20: そしてこの数字はGitHubによると現時点で日本で一番多いそうです🎉 サイバーエージェントではGitHub Enterpriseが導入されており、事業部や事業単位でOrganizationを保持してお
｢伝説のエンジニア｣が明かすエヌビディアの死角
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Twitterのタイムライン、エンジニア的には絶対に作りたくない→ユーザーが思ってるより複雑な構成らしい
失敗から学ぶ 技術的負債との正しい歩き方 / learn from predecessors
引っ越しのため内見に行ってきたらどの物件も「無料インターネット」を提供していた→光ファイバーが引けないし全然早くない
めんどくさい作業を改善できるようになるには - Konifar's ZATSU
PC-8801mkIISRで「漢字BASIC」を制作、大学の研究室ではApple IIを使用… 杜甫々氏が「とほほのWWW入門」を開設するまで
【実話】スキル不足でフリーランスエンジニアになった末路 - みんなのシステム企画
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考”
新入社員に向けて私が3年間で読んだ技術書を紹介する - Qiita
NVIDIAのCEOが「AIがコードを書くのでもうプログラミングを学ぶ必要はない」と発言して議論を巻き起こす
米国連邦政府におけるクラウド戦略「Cloud First」の失敗と教訓｜ミック
非エンジニアの自分がウェブ地図サイトを公開するまで - Qiita
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
ITスキルを「本」で高める『技術書の読書術』
僕が考える「良いコード」 - give IT a try
休日にシステムエンジニアは勉強するべきかどうか - orangeitems’s diary
ITエンジニア「勉強し続けられない人はこの仕事に向いてない」
全ITエンジニア必読書である「世界一流エンジニアの思考法」を要約してみた
中途入社のソフトウェアエンジニアがWebサービス開発に参加するとき役立ったこと - kymmt
「コンピューターの基礎は若い時に学んでいてほしい」 ソフトウェア開発組織が持つべきカルチャーとは
MetaのTwitter競合「Threads」、開始は7月6日午前8時になぜか前倒し
セキュリティエンジニアを目指す人に知っておいてほしい組織 - FFRIエンジニアブログ
新任エンジニアリングマネージャーのための「ぼうけんのしょ」
就職氷河期世代とIT業界／若手世代が注意するべき轍｜久松剛／IT百物語の蒐集家
SREはインフラエンジニアだけでなく、みんなの活動 - ytake blog
失敗から学ぶシステム開発委託 - CARTA TECH BLOG