最近のWeb3への雑感
Web3とは何であったか トークンとコントラクトと誰からでも見える台帳を使ってなんか出来そうなことないっすかねくらいの思想または活動 自動販売機で金入れたら人を解さずにジュースが買えるような感じで、トークンを支払ったら人を解さずにトークンが買えたり付与したりできる仕組みを作れるスマートコントラクトというのがあり、これなんかに応用できないっすかみたいなことだけだったはず NFTとかDAOとかもその応用例の一つなだけにすぎない トラストレスとか分散性みたいな話はEthereumのDocsには一部記述があるがあくまで理想論として語ってるだけ。会社がvisionをHPに書いてるようなもん。 Internetの技術が置き換わるとかBigTechを打倒するみたいな対立構造を煽るような話では全く無い そもそも既存のインターネットの上に成り立っているし、分散されたそのノードはどこのサーバーで動いているんだ
Stack Overflow Developer Survey 2022
In May 2022 over 70,000 developers told us how they learn and level up, which tools they’re using, and what they want. Read the overview → Methodology → The questions we ask in our annual survey help us improve the Stack Overflow community and the platform that serves them. The challenge and opportunity for us is to continue expanding and improving our ability to help all developers and to make th
「技術的負債」への処方箋と「２つのDX」 - Qiita
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
ソフトウェアエンジニアと技術力 / developer-lifework
Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://soudai.hatenablog.com/entry/2017/06/03/183508 - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://speakerdeck.com/twada/worse-is-better-understanding-the-spiral-of-technologies-20
ITエンジニア本大賞2021
2021 大賞の発表！ ITエンジニアのみなさんとおすすめの本を選ぶイベント「ITエンジニア本大賞2021」の第一弾のWeb投票、第二弾のプレゼン大会（オンラインイベント）が無事に終了し、プレゼン大会をご視聴されたみなさんによる最終投票で「技術書部門大賞」、「ビジネス書部門大賞」が決定しました。また、各特別ゲストによる「特別賞」も選出しました。ご参加いただいた皆さま、ありがとうございました！ Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち 出版社：ラムダノート 監修：株式会社VOYAGE GROUP 編集：和田卓人 投票した理由や感想などみなさんからのコメント 自分が在籍していない場所でのプロジェクトのリアルが覗ける書籍は他にないので、興味しかない。 日本社会のこれからのロールモデルというプレゼンに興味を覚えた。 感想で生々しいという声も多く、具体的な事例
CTO不在の企業で開発組織を作っていくために大事なこと｜BTO
おはこんばんちは!!尾藤 a.k.a. BTO です。 これは CTOA Advent Calendar 2020 の5日目の記事です。 今までウノウとUUUMの2社のスタートアップでCTOを足掛け10年近くやってきました。経歴柄、CTOのいない企業から開発組織の作り方の相談を受けることが多いですが、やはりCTOが不在で開発組織を作っていくのは非常に困難です。とはいえ、転職市場に都合よく即戦力になりうるCTO人材が簡単に見つかるのも稀です。そこでCTOが不在の中で開発組織を作っていくために大事なことをまとめてみました。 開発組織作りで大事なのは採用ではなく環境作り開発組織作りで大事なことはいろいろありますが、最も大事なのは採用と環境の2つではないかと思います。環境が良くなければ優秀なエンジニアは採用できないし、優秀なエンジニアに来てもらえなければ良い開発環境を作ることができません。いわゆる
エンジニアの職人芸を継承すべし | 外道父の匠
『職人芸』。それは、その人にしかできない、または他より圧倒的な品質・精度・速度で仕事を遂行する技術力、というものが確かにあります。 そのような崇高な技術は、どこから来て、どこへ行くのか。そんな圧倒的ポエム回。 職人芸とは 言い方はなんでも良いのですが、組織には上級的なエンジニアが一定割合いて、おそらくその人にしかできない仕事や、手慣れていて効率的に済ませられる仕事を任せられていることでしょう。 そういうエンジニアはたいてい『職人芸』と呼べそうな技術を修得しています。例えば、高精度な設計・高難度な機能実装・的確なコードレビュー・精密な試験・堅牢な運用などなど。 システム提供を大雑把に工程で分類すると、企画・設計・構築・試験・運用 といったところでしょうか。ちょっと外すと研究などもアリですね。それぞれの工程において、集中的に従事して得る職人芸もあれば、多岐にわたる経験によって生まれる職人芸もあ
プロダクト負債というもの
root Design Meetup #1 「UX負債への取り組み」 - connpass に参加していてUX負債とは技術的負債に非常に近いものを感じた。 そこから考えてみると、特にUXや技術に関わりなく共通的に負債を概念を考えられるのではないかと思ったので書く。 現状プロダクトを運営していく上で積み重なっていく問題を横断的に指す言葉として、ここでは「プロダクト負債」とする。 当初「サービス負債」としていたが、いくつか検索したところ、「product debt（プロダクト負債）」は既に使われている用語のようなので書き直した。 Googleで検索した範囲では「プロダクト負債」だと数件のヒットがあった。 「product-debt」だとそれなりの件数がヒットするが、いくつかみた範囲ではここで紹介している内容より狭い範囲を想定しているように見えた。 （が、この記事は翻訳ではないため、既存の概念と
「クリエイターがお金にこだわるなんて汚い」という、謎の意識は滅んでほしい。
「お前の技術なんて大したことない」 「そんなこと誰にでも出来る」 って思わされて、結果的に作品や自分の技術を安く買いたたかれてしまっている人、多分目に見える範囲外でもたくさんいるんじゃないかなあ、と思ったんです。 定期的に話題に上がるテーマとして、「ハンドメイド作品の値切り問題」というものがあります。 ちょっと前の記事なんですが、例えばこういうお話があります。 「材料費100円とかでしょ」ハンドメイド作家に心無い値下げ要求 テレビ番組が材料費と販売価格の差が大きいと放送 この購入希望者は、1200円で販売予定のキーホルダーに対し「500円くらいとか無理ですか？」と指値を提示。その根拠は、「そんなに材料費とかかかってないと思うので」「材料費100円とか200円とかじゃないんですか？」というものだった。作家が、高い素材を使用していることや、繊細な作業が必要で加工に時間がかかることなどを丁寧に説
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
Webエンジニアおかあさんそのほか｜やきとりい
IT業界で働く女性が、母親をしつつ仕事も続けるビジョンを持ちにくいよねー実例が少ないからねーという話を聞きました。このnoteは、その1サンプルの提供のために書いています。 他の人に必ず当てはまる話ではないけれど、たしかに今なんとかかんとか回している子持ちWebエンジニア（フルタイム）のわたしの話です。 すごく優れているわけじゃないし、人並外れて努力しているわけでもない。そんな真面目でもない。 ただ毎日、できる範囲でなんとかしています。 2018年現在のステータス - Webエンジニアとして8年目くらい - こども（ぱんださん・仮名）は1歳8ヶ月 - パートナー（ささださん）もエンジニア、時間の融通が効くお勤め - 会社は株式会社万葉。SES契約での業務が主ですが常駐するスタイルではなく、働きやすさと技術を大事にするホワイト企業 目次- 今の働き方のスタイル（日々のタイムスケジュール／イレ
技術顧問業を始めて2年がたった - おもしろwebサービス開発日記
2年ほど前から「フリーランスRails技術顧問」みたいな肩書で複数社のお手伝いをしています。すると知り合いに、技術顧問って実際どんな感じで仕事してるの？と聞かれることが多いので、「これ読めばわかるよ」と言えるように実際にどんなことをしているのかまとめておこうかと思います。 ざっくりどんなことしてるの お手伝いしている会社によってやっていることが違うので一言では答えにくいですね。基本的に「僕の身につけたRailsとシステム開発の知見を提供する」というのが共通しているところ。僕はCTO経験などないのでエンジニア組織についてはあまり触れず、技術寄りの知見について特化して伝えている感じです。 だいたい次のような会社が対象。全部Railsを使っているか、これから使おうとしている会社です。 創業から数年たち業務が拡大してきたが、負債が溜まって身動きが取りづらくなってきたのでちゃんと体制を整えたい 負債
データ指向アプリケーションデザイン
AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、
ブロックチェーンは何も解決しない。｜es
はじめて、ブロックチェーンを知った時は興奮したものです。なぜかと言うと、「分散化した環境下で、合意形成が取れる」と謳っていたからです。 「これは民主的だな、色々な問題が解決する」と夢中になりました。 「ブロックチェーン」という言葉が、どうも一人歩きしていると感じたのは、ビットコインやイーサリアムを、よく理解してからでした。 よくよく考えれば、「分散化した環境下で合意形成」と言うのは、ビットコインのことだったのです。「ブロックチェーン」は、ビットコインや他の暗号通貨を実現するための、一要素にすぎません。 今回もJimmySong氏の論考を訳してみました。 以下、本文。 ブロックチェーン技術は真新しいものであり、十分な時間を投資すれば誰かが、通貨以外に役立つものを作るということを、ビジネス界隈では多くの人が信じています。これこそ私が「ビットコインではなく、ブロックチェーンを」症候群と呼んでいる
技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
YOOT.COM: メニューと料理はちがいます その2
私がライカ系のカメラにはまっているものですから、周囲の知人に、なるだけ自分と同じようなカメラを買わせて仲間に引き入れようとする傾向があります。しかし、そんなことをここ数年続けてわかって来たことがあります。私の周囲にいる人たちは、カメラ好きは多いけれど、写真好きはほとんどいない、ということ。「どこそこのメーカーはXXX万画素のフルサイズを出したけれど、ノイズが多いと評判で」とか「どこそこはAPS-CサイズのCCD搭載の新型を予定しているようだ」とか、そういう情報に詳しい人は、さすがゲーム業界だけあって、あちこちにいます。しかし、「じゃ、いちどお互いの傑作写真を持ち寄って見せ合いませんか」となると、てんで反応が鈍くなる。知人のS氏の写真を見せてもらったことがあるんですが、その膨大なレンズ資産とはかけ離れた、まるで被写体に興味のない写真ばかり。「Sさんはカメラが好きなのであって、写真は別に好きじ
データセンターの作り方
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方
Noを伝える技術 #pmconf2021
F1走行を360度、自由に見渡せるパノラマ「動画」