youkoseki.com 2021年だから人類はHTMLを手打ちしろ 新しい年だ。人並に新しいことを始めようなどと考える人もいるだろう。しかし、なにを始めればいいのか？　僭越ながら一つ提案をさせてもらえるなら、私はこう言いたい。HTMLを手打ちしろ。ハイパーテキストマークアップランゲージを学べ。なぜなら、個人がコツコツとタグを手打ちしたウェブページには暖かみがあるからだ。 私は中学一年生のとき、はじめてパーソナルコンピュータを買ってもらった。中学受験がうまくいったら買ってもらえるという約束で、受験には失敗したのだが、買ってもらったのだ。中学時代、ほとんどずっとパソコンと向かいあっていたが、CONFIG.SYSとAUTOEXEC.BATを書き換えてメモリ残量の上下に一喜一憂していた記憶しかない。あとA列車で行こう4や、ルナティックドーンのようなアートディンクのPCゲーム。Windows 3

Introducing amazing graphs which are drawn by listed Japanese companies in 2020.Read less

マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その

TL;DRクラウドネイティブな時代のビジネスではWebサービス活用は必須Webサービスをセキュアに利用していくには管理やセキュリティ面での工数・コストが増えるこの工数・コストを下げることこそがWebサービス活用推進ひいてはビジネスの加速に繋がる工数・コストを下げる為に導入するWebサービスにSAML/SSOは必須ログインをSAML/SSOに限定出来ることまでがマストWebサービス利用におけるセキュリティ面で一番重要なのがID周り個々のWebサービスのセキュリティ対策よりもID管理に特化したシステムに任せた方がよっぽどセキュア（餅は餅屋）Webサービス導入時には値が張ってもSAML/SSO出来るプランで契約するSAML/SSOが出来ないことによるデメリット（工数・コスト）の方が、SAML/SSOを有効にできるプランにアップグレードする費用に勝るB2BのWebサービスを提供する企業は全プランに

はい、今回はみんな大好き（大嫌い）SIerについての話である。 デジタル庁の動きに駆動されて、日本で何度目かの内製推進が盛り上がろうとしている。 日本のITシステム開発がうまく行かない原因としてしばしば挙げられるのが、ユーザサイド（非IT産業）にエンジニアやプログラマなどのIT人材が不足しているというものだ。確かに、日本が欧米と比較してIT企業にIT人材を集中的に配置しているのは事実である。 こうしたIT人材の偏りによって、アジリティの高い開発ができない、CI/CDやDevOpsが進まない、というのは当たっているし、ユーザ企業も自らIT人材を雇用して内製を進めるべきだ、という議論にはもう十年以上の歴史がある（筆者が追えていないだけでもっと古いかもしれない）。 この時、悪玉として批判にさらされるのが、今回の主役であるSIerという存在である。日本における内製推進は、しばしばSIer批判とセッ

はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も

ざっくり年収1,000万円のエンジニアが10名いる会社では、年間1億円の技術投資がなされているわけですが（地代家賃、ライセンスフィー、PC代など含めるともっと）、年間1億円を正しく詳細に把握して、投資をコントロールできている会社は少ないと思います。会社が創業期であれば、最低限作らなければならない機能などは分かりやすく見えていたりするのでまだしも、そのプロダクトでしっかりとした収益が成り立ち、上場企業となるようなレベル感のプロダクトに対する技術投資となると、一部の大きなプロジェクトは把握していても、細かな投資ポートフォリオを常に把握することは難しいのではないでしょうか？今回はこの部分に一石を投じてみたいと思います。 技術投資量を見える化する 投資の最適化とは言いますが、最適化というのは「To Be」の話ですので、まずは「As Is」を知らなければ話になりません。その、まず「As Is」を知る

こんにちは！ delyでkurashiruというレシピ動画サービスのUIデザイナーをしている@ymdscoです。 今年もやって参りました、delyのAdvent Calender！この記事は第1日目の記事になります。 また、今年は社内の参加人数も増えて、なんと、同時に2つのカレンダーが更新されていきます！ dely Advent Calender #1 dely Advent Calender #2 本日更新されるもう１つの記事は、望月さん(@0000_pg)の Ruby 3.0へ向けて、型周りをさわってみた です。 我々はいちごでサンタさんをつくりながら、型と向き合っていかないといけません🎅🎄 ↑　こんな感じの記事なので、俺はゆるふわ技術ブログが読みたいんじゃという方は是非読んでみてください。 はじめに私はdelyに6月頃転職したのですが、kurashiruのリデザイン案を20ページ

この記事は Build your own React を翻訳したものです。 Reactを1から書き直していきます。 実際のReactコードのアーキテクチャに従いますが、最適化機能と必須ではない機能は今回は実装しません。 Step 1: createElement関数 Step 2: render関数 Step 3: 並列モード Step 4: ファイバー Step 5: Render Phase と Commit Phase Step 6: 差分検出 Step 7: 関数コンポーネント Step 8: Hooks Step 0 復習 最初にいくつかの基本的な概念を確認しましょう。 React、JSX、およびDOM要素がどのように機能するかをすでに理解している場合は、この章はスキップしても構いません。 今回は、次のわずか3行のコードをReactアプリの例として使用します。 const ele

このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。 （品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。） --- 概要 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル

人間にまつわるセキュリティを考える本連載。今回のテーマは「ヒューマンエラー」です。個人の意識だけに原因を求めてもうまくいかないヒューマンエラー対策について考えます。 連載目次 ヒューマンエラーを考える 心理学などの知見を借りながら、「人間のセキュリティ」を考える本連載。第5回では、組織の「ヒューマンエラー対策」を扱います。情報セキュリティに限らず、多くの事件・事故は、ヒューマンエラーが主要な原因となって起きています。 図表1はNRIセキュアテクノロジーズが2015年に行った調査の結果です。これを見ると、企業におけるセキュリティ事故の大部分は、「ヒューマンエラー」と「サイバー攻撃」によるものだと分かります。また、この調査の中でサイバー攻撃として分類されている幾つかの項目も、考え方によってはヒューマンエラーに起因するものと捉えることができます（標的型メール攻撃など）。 図表1　過去1年間に発生

※この記事はGYOMUハックAdvent Calendarの2日目の記事です。 はじめに日々、業務をしていると、どうしても発生してしまう作業ミス。どんなに気をつけていても、何かの拍子にうっかりミスをしてしまったことが、誰にでも少なからずあるのではないでしょうか。ミスした結果、大きな問題に繋がらなければ幸いですが、もし会社や顧客へ損失を与えてしまった場合、近年では必ずと言っていいほど「原因分析」「再発防止策」を盛り込んだ報告が要求されます。何人もの人が多くの時間を費やしてミスの原因分析を行い、挙がってくる再発防止策の多くは「社員の気を引き締めて、ミスの再発防止に全力で取り組む」「再度、作業手順を周知徹底する」「ダブルチェックを徹底する」といったもの。 その後、職場に緊張感が生まれ、確認作業を増やしたことで、一時的に作業ミスが減ったように見えます。しかし、職場全体で緊張感の高まりによる精神的負

システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生

はじめまして、どうも、つんく♂です。 作詞・作曲を中心に音楽やエンタメ全般のプロデューサーをやっています。モーニング娘。のプロデュースから始めて、アイドルやアーティストなど、たくさんの作品を生み出してきました。 『リズム天国』などのゲームや、アニメにも関わっています。今は、「つんく♂エンタメ♪サロン」のメンバーで、「中2」をテーマにした映画制作を始めたばかりです。 声の病気をしたので今は歌えませんが、その分、日々の作品作りと、次世代のスターやクリエイターの応援に注力しています。 いちクリエイターとして、noteを始めますさて、今月から、個人noteを本格的に始めてみようかなと。 というのも、僕の中には、自然に生活していて「これいいよ」との情報が2回以上重なって耳に入ってきたものが「売れる」「ヒットする」という過去データがあります。なので、そういうものに出会った時は、出来るだけすぐに試すよう

決算説明会資料というものがあります。株主に向けて、当期あるいは通期の決算説明を行うための資料です。主に企業のIR室（Investor Relations）、つまり企業が株主向けに現況や今後の見通しを広報する活動を主に実施する部門が書きます。 そのIR室の役割の一つに決算説明会資料の作成がありますが、これはすごく骨の折れる作業な一方で、報われない作業でもあります。なぜなら、IR担当部という全然力がないような部が、関係各所に数字をもらったり現況を把握したりレビューしてもらったりし、その上えらい人からも余計な口出しが色々と入るからです。労多くして、という典型例ですね。 しかし、今回ご紹介するGoodpatch社についてはそれはあてはまりません。なぜなら、Goodpatch社は「デザイン」という業務が事業に大きく影響するからです。そんな会社が、自社の発表する資料で手を抜くわけがなく、またそれの見栄

まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

GDG DevFest 2020 LT大会 https://tokyo.gdgjapan.org/devfest2020/schedule/1/127

承前 : Part-3 https://anond.hatelabo.jp/20201005082738 次回 : Part-5 https://anond.hatelabo.jp/20201008100556 前提IT系の会社を前提とする。 Individual Contributor (IC)を前提とする。採用やインタビューの話をするときに、応募者にそれなりの学歴・素養があることを前提とする。 (追加) TCの話をする際、すべての数字は４年間の平均、かつ課税前を前提とする。要は4年間の額面収入の合計を4で割ったもの。 (追加) 個々人の選択によって大きく変わる社会保障費の会社側負担などは無視して話を進める。つまりW-2のBox 1の数字を取り扱う。L4 at GOOG/FBL4は一人前の技術者と目されるランクである。L3で入社した社員の多くは数年以内に昇進するし、逆に5年たっても昇進し

承前 : Part-2 https://anond.hatelabo.jp/20201004112526 次回 : Part-4 https://anond.hatelabo.jp/20201006121559 anond:20201002000619 levels.fyiに書かれているRSUの値はvestでなくgrantベースなので、これにbaseとbonusを足しても実際に貰うことになる年収というかW-2の値とは違うものになります... その通り。おそらく上記の方は米国在住の方であろう。 額面と手取りについてまだ扱っていなかったので、実際、重大な誤解を与えうることに気付いた。そのため今回は予定を変えてこちらを取り扱う 前提IT系の会社を前提とする。 Individual Contributor (IC)を前提とする。採用やインタビューの話をするときに、応募者にそれなりの学歴・素養がある