React の人が「jQuery でいいじゃん」って言われまくって狂う(例: erukiti さん)みたいのはわりとよくみるけど Vue の人とか Angular の人とかがこうなってるのあんまなくて、 mizchi が目立ったのが悪いんではってさっき気づいた
あー・・・
デル テクノロジーズは、全国の中小企業（従業員数1〜99人）の経営者および従業員1072人に対して実施したテレワークに関する調査結果を発表した。3割強がテレワークを導入済みと回答した一方で、ほぼ半数の47.2％は「導入しておらず、検討もしていない」と答えた。
業種別では、テレワークの導入が最も進んでいるのは「情報通信業（69.2％）」で、「金融・保険業（53.7％）」が続いた。一方、「導入しておらず、検討もしてない」と回答した47.2％の業種別の内訳は、「建設業（64.8％）」「製造業（58.5％）」が上位で、業種によってテレワークの導入率に大きな差が出る結果となった。
テレワークを導入しない理由については、「業種として難しい」が7割を超え、業種によりテレワークの実現が困難である状況が顕著になった。また、テレワークを導入する／導入した理由では、「働き方改革を推進」が全体の約半数の48.8％でトップで、続いて「ワークライフバランスの向上（35.3％）」「業務生産性の向上（29.2％）」「オフィスコストの削減（24.7％）」と続く。
そりゃまぁそうだろうという結果だ
これまでフリーランスプログラマの視点から語ってきけど、雇う側は、なんでフリーランスプログラマをつかうんだろうか。社員じゃだめなのか。
（中略）
まだ開発のためにあたらしく社員を雇用する余裕がないとき、経営の安定していない状況で新規プロダクトを立ちあげたいとき、とりあえずお試しでコンセプトを検証したいプロトタイピングなどを目的として仕事を依頼されることが圧倒的に多かった。あるいは、正規の社員が見つかるまでの繋ぎか。ガッと作って納品して、ちゃんと動いてますね、ではさようならという仕事ばかりで、すでに軌道に乗っているサービスの運用フェーズや改修にかかわったことはほとんどない。
これはまぁ確かに。
こういったプロジェクトとのかかわりかたが多いため、書いたコードの長期間にわたる保守をほとんどしたことがない。書きあげて、お客さんにわたしたら終わり。あとはそれをお客さんが好きにつかうだけ。どうつかわれるかはまったく関知しない。
（中略）
つまり、じぶんの書いたコードのお守りを長期的にすることが基本的にない。だから、メンテナンス性の高いコードを書く動機がない。もちろん、かならずしもめちゃくちゃなコードを書くということではなく、ぼくの知り合いの範囲では、どちらかというとちゃんとしたコードを書く人が多いと思うけど、構造的にしっかりと書く理由がないという話。
確かにフリーランスの人のコードは良くも悪くも「動けばいい」「適切な結果が返却されればいい」レベルのものばかりで、高い品質のコードが書ける人は極少数。
まぁ、先述のようにプロトタイプやそれに類するものがメインになるので、あまりコード品質が問われないという面もある。
逆にコード品質が問われる部分にフリーランスエンジニアを投入してはいけないという事なのだろう。
フリーランスプログラマに向いてる人
ぼくのフリーランスプログラマ観はこのツイートにまとめられる。
長年フリーランスやってるけど、フリーランスの一番のメリットは自由な生き方ができるところ。だから、自由を強く求める性分の人にフリーランスは合ってる。
あたえられたタスクを淡々とこなすことができる人、人からあたえられたお題でプログラミングをずっとやっていることが苦痛でない人は、フリーランスプログラマに向いている。
自由な生き方ができると言いつつ、仕事上の自由が全然無いのは許容できるんだろうか？ トレードオフの問題ではあると思うけど。
自分としては一日の大半は仕事に費やす以上、仕事上の自由（裁量）の方を重視するし、「より良い開発」「より良いコード」が重要だと思うので実装だけでなく全てのフェーズに関わりたいので今後もフリーランスをやることはなさそうである。
社内エンジニア勉強会
若手エンジニアキャリア相談ビアバッシュ
少人数固定チーム化&リーダー廃止
戦略会議の議事録説明会
戦略会議の議事録説明会は弊社でもやってほしさある
「そういうふうに」書いているのだろうけど、ひとつの会社で栄達を求めようとすること自体が無意味なのだ。
合わないと思ったら即転職した方が給料は上がるし、QOLもよい。
そして、そのようにあるように常に研鑽を怠るべきではないのだ。
Goのソースコードを調べていくと、Goは最低2分毎にガベージコレクションを実行することがわかりました。つまり、ヒープの増加とは関係なく、ガベージコレクションが2分以上実行されなかった際にGoはガベージコレクションを強制的に実行しているのです。
へぇ
本当に迷惑なんだ。
センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。
センスのない奴は、普通の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。
最近見た例を書いてみる。2次元のテーブルを扱うJSONだ。
普通の人なら、何も考えず以下のような実装をするだろう。
[ {fieldName: "id", title: "id", type: "number"}, {fieldName: "name", title: "商品名", type: "text"}, {fieldName: "price", title: "値段", type: "number"} ]
[ {id: 1, name: "商品A", price: 100}, {id: 2, name: "商品B", price: 200}, {id: 3, name: "商品C", price: 300} ]ところが、センスのない奴はたとえば以下みたいな意味不明な実装をナチュラルに行う。
[ {id: "0-0", val: "商品名", type: "text"},{id: "0-1", val: "値段", type: "text"}, {id: "1-0", val: "商品A", type: "text"},{id: "1-1", val: "100", type: "number"}, {id: "2-0", val: "商品B", type: "text"},{id: "2-1", val: "200", type: "number"}, {id: "3-0", val: "商品C", type: "text"},{id: "3-1", val: "300", type: "number"} ]一応言っておくと、これは実例の一部を分かりやすいように切り取っただけであり、本物はもっとひどい。
センスのない奴っていうのは、スキル云々の問題ではなく、そもそも認識している世界が常人と異なるから、矯正は無理だし、チームにいると非常に迷惑なんだ。だから、プログラマにはならないでくれ。
残念なことにいつまで経っても初級者レベルにすら到達できないエンジニアは存在する。
やる気やモチベーションの問題もあるだろうが、同じ環境でスキルに差が付くという事はやはり適性が無かったのだろうと結論せざるを得ない事も多い。
そのような人々を飼い殺しにしてもお互いにとって損であると思う。
気が重い話ではあるが、チームから去ってもらうように説得するしかないだろう。
サーバーサイド一筋5年の優秀な同僚のVue.jsのコードをレビューしたことがあります。責務が分割され、メソッド毎の処理がわかりやすく、とても綺麗に書かれており、特に指摘するところなくLGTMを出しました。
「調べながら書いた」とのことで、この経験から以下の洞察を得ました
・サーバーサイドで、OOPのベストプラクティスを理解している人はフロントでもクリーンなコードを書く
・SOLID原則（クラス単位）とレイヤードアーキテクチャを理解するとフロントで応用できる
・「サーバーサイドからフロントエンドエンジニアに転身した人」というだけで、侮ってはいけない
・情報収集力は一種のスキル。サーバーサイドでもフロントエンドでも役に立つ
結局、クリーンなコードを知っている人は、サーバーサイドでもフロントエンドでもコンポーネントごとの責務がわかりやすく、シンプルなコードを書くということです。
さらに、ここから一歩踏み込みますが、情報収集力とWebを構成する技術に対する理解さえあれば、フロント周辺のツールの利用経験の有無は重要ではないと思ってます。
ツールはあくまでも道具です。そのツールで解決したい課題とそれに対するにアプローチ、トレードオフを理解すれば、
経験と熱意と興味があれば、基本的な使い方はマスターできます。あとは「最新の書き方」（時に振り回されること）や、「コミュニティが発見したベストプラクティス」を先達が教えれば済むことです。サーバー側でもフロント側でもどちらか一方に通じ、ツールに対するメンタルモデルを形成すれば、
もう一方の学習コストは大幅に減り、いわゆる「上達」につながると考えています。なので、フロントとサーバー側で分けるのではなく、ミクロな視点では「OOPによるクリーンなコードの書き方」、より大きな視点では「Webを支える技術に対する理解」「中・大規模のソフトウェアの設計」「システム全体の
のアーキテクチャ」のスキルで判断するべきでしょう。
なお、私自身はCSの学位を持たないWeb Developerで、サーバーサイドはPHP、フロントエンドでReactを書いているものであることを付言しておきます。もちろん立場が違えば視点も異なると思います。
ただし、フロントのコンポーネントの分け方だけは、自分なりの指針はまだ見出せないでいます…。あれは何を参照して何をモデルとすればクリーンになるのか、試行錯誤中です
ラウドネス・ウォー（音圧戦争）という言葉がある。音響機器の技術を駆使して、音がひずまない範囲で、音楽全体の聴覚上の音量を、他の楽曲より、かさ上げすることをいう。J-POPなどロック系の楽曲で主に使われる手法だ。
音圧＝音の圧力が高いので、パッと聴いた瞬間、印象に残りやすく、楽曲への好感度を上げる効果が期待できる。アーティストやレーベルの中には、他の楽曲よりも音圧を上げることで、自分たちの曲を少しでも目立たそうという考え方で意識的に音圧を上げる人達がいる。これが音圧戦争の概要だ。
しかし、Spotify、Apple Music、YouTubeといったストリーミングサービスが主流の現在、その“個性”が具合の悪い結果をもたらすことになる。プレイリストという形で、さまざまなアーティストの楽曲が混然一体となって放送のようなスキームでリスナーに届けられるのがストリーミングサービスの特徴だ。そうなると、楽曲により音圧に差異が生じたら曲の切り替え時に突然音が大きくなったり小さくなったりし、リスナーはその都度音量を調整する必要が生じ、心地よく聴くことができない。
そういうことだったのか
聞いてたけど、途中で寝てしまった。
「UiPath Test Suite」は、RPA領域におけるソフトウェアテストの設計・管理・実行の効率化で培ったテクノロジーを活かして、RPAだけでなくさまざまなアプリケーションのテストに対応している。
テストケースの設計・管理ツールである「UiPath Test Manager」、開発ツール「UiPath Studio」にテスト用の検証アクティビティを追加した「UiPath Studio Pro」、管理ツール「UiPath Orchestrator」にテスト用機能を追加した「UiPath Test Orchestrator」、テスト実行用ロボット「UiPath Test Robots」で構成される。
パスワードを送るのに同じ流通経路のメールを使うと、セキュリティは担保されない。同じ通信経路であるメールでパスワードを送ると、攻撃者がいた場合、同じ通信経路に流れるものは一挙に盗み見られるので、セキュリティは担保されないのだ。
また、ZIPファイル自体は問題ないとされているが、ZIPファイルの暗号化には複数の方式があり、一般に使われている方式は弱い暗号であるため、悪意のある攻撃者に対しては、脆弱だという指摘もある。
パスワードをSMSで送ったり、事前のオフラインで共有したりするなど、メール以外の流通経路を使えば問題はない。ただ、現状そのように周知徹底されることはほとんどないという。
さらに崎村さんが「有害」と言う点。それは、メールの添付ファイルを使った攻撃に対して、暗号化されたZIPファイルは、中身がわからないが故に、企業が有害な中身がないかチェックする「マルウェア対策」を無効にしてしまう。そのため、かえって受信者のセキュリティリスクを高めている。
結局のところ、組織を飛び出して自分で組織を作った方が楽という話になりそうな
人月商売界隈における技術者の経歴詐称はマジで存在する。かつて自分も勝手に経歴を盛られていたことがあった。
2次請けぐらいまでだとある程度節度がある感じだけど、それ以降は「とりあえず現場に放り込めればOK」のノリになるので少々の経歴詐称は方便みたいになっている。
酷い例ではまったくの新人が1年間の開発経験があるとして放り込まれた事例も見たことがある。
とはいえ、中抜きをする中間の会社は紹介手数料が入れば文句は無いし、元請けもとりあえず頭数が揃えられれば文句は無いし、派遣元の会社も売上が上がるので文句は無いという一種の確信犯的共犯関係が成立しているので、特に問題になることはない。
なお、エンジニアは死ぬ。
UbuntuとFirefoxを組み合わせて、Chrome OSのようなウェブベースのOSを開発しようとしているようです。
Coming soon! とありますから、既に開発はある程度進んでいると考えられます。
Firefox OSは、Androidとの比較で語られました。自由にアプリをインストールして使う、いわば「フル機能」のOSです。
一方で、この「Ubuntu Web」に関しては、もっぱらChrome OSとの比較で語られています。
初期のChrome OSのように、サードパーティのローカルソフトウェアのインストールができない形なのか、あるいはLinuxのソフトウェアをインストールできるのかはまだ不明です。
ですが、Chrome OSのように軽量で、低スペックのPCでも動作して、Firefoxブラウザを稼働させるというのが前面に出たOSである可能性が高そうです。
ふーむ
本講義は，東京大学計数工学科で2020年度S1/S2タームに開講されている"システム情報工学特論"の一部として行われるものである．
本講義(計3回)の目的は，クラウドの初心者を対象とし，クラウドの基礎的な知識・概念を解説する． また， Amazon Web Service (AWS) の提供するクラウド環境を実例として，具体的なクラウドの利用方法をハンズオンを通して学ぶ．
特に，科学・エンジニアリングの学生を対象として，研究などの目的でクラウドを利用するための実践的な手順を紹介する． 知識・理論の説明は最小限に留め，実践を行う中で必要な概念の解説を行う予定である． 受講生が今後，研究などでクラウドを利用する際の，足がかりとなることができればこの講義の目的は十分達成されたことになる．
コードに対する通常のコメントについては必ずなんらかの意図を持って書かれるため「正しく計算できる」のような内容になることはまずないと思うのですが, テストの説明についてはフレームワークによっては必須になっているためか, あまり内容について意識しないまま書かれてしまうことが多いように思います. 基本的には通常のコメントと同じで, 読者にとって意味のあることを書きましょう.
ちなみにここまでは実装の後にテストを書いている, あるいはそのようにして書かれたテストコードを読んでいるという想定でしたが, TDD のようなテストファーストな開発手法にも思いを馳せてみると, ここではテストコードが "正しい" ことが何であるかを定義すべきであるはずなので, やはり「正しく計算できる」といった説明には何の意味もない (自明あるいは循環定義) ことになります. とはいえテストを先に書いていると何をテストすべきかが意識の中心にあるはずなので, あまりこういった中身のないことは書かなさそうな気もしますね.
テストケースの確認項目が「○○が正しいこと」とか書いてあると結構渋い気持ちになってしまうよね
Microsoft傘下のGitHubは米国時間7月16日、アクティブな公開リポジトリー全てのスナップショットをノルウェーの保管施設で長期保存するという「Arctic Code Vault」プロジェクトの節目となる、コードの収容作業を完了したと発表した。
このリポジトリーには公開コードリポジトリーと、休眠中の重要なリポジトリーが含まれている。またこのスナップショットには、各リポジトリーのデフォルトブランチにおけるHEADから100KBを超えるバイナリーを省いたものが収録されている。各リポジトリーは単一のTARファイルとしてアーカイブ化されており、効率を追求するためにほとんどのデータはQRコードとして収録されている。
また、各リポジトリーが格納されている場所の一覧とデータの復元方法が、人間の目で確認できるインデックスとガイドによって提供されている。
それらのコードは1000年後でも価値のある情報足り得るだろうか？
データベースライブラリであるTkrzwの初版をリリースした。Kyoto Cabinetの正式な後継製品である。本家のサイトはここである。設計目標の通り、高速かつ堅牢で多目的に使える実装になったと思っている。私の下手な英文を読むのも辛いだろうから、ここに概要を書いておこう。
おっ
Kyoto Cabinetそのものの更新はしないのかな？ と思ったら次のような記述が。
余談。KCのメンテだが、雇用契約の関係でもう更新できないのが実情だ。いろいろ大人の事情があってね。今回はそうならないようにうまいこと進める所存。
ふーむ。
昔、給与に目がくらみ、知識ゼロでプロゲラマー募集面接に行った事があり「えっとポインターは理解されていますか？」と言われ。なんのことやろ、キャシャーンの犬かな。よく分からんけど「知ってます」と答え、無事知識ゼロで携帯の組込開発をする事となる。
なぜか知らんがその部門のリーダーにさせられていた。ちょおま、って思ったけれど後の祭り。年齢的にそうなったぽい。とりあえず受かったからにはクビにならないようにしなければならない。使用するのはＣ言語というやつらしい。聞いたことはある大丈夫や。
Webは好きだったのでサーバーを借りてXoopsとかアップロードして遊んだ事はあるやで（面接時：Webのプログラムしていましたと言っておいた）。とりあえず今からＣ言語の本を買うしか無いぞ。
本屋に行ってさがすと、C、C++、C#とかいっぱい言語の種類が・・アホかこいつら統一しろと思いながらとりあえず基本と思う猿でもわかりそうなCの本を買った。始まるまでの数週間でマスターしなければいけないが、ぶっちゃけ読んでもよくわかんないまま仕事が始まった。
冠婚葬祭でしか着なかったスーツでの出社。会社に入るとセキュリティーの番号とか打ち込んでの入室、映画かよと思いながら、部屋に入ると百人数十人からがそのフロアに居た。ビビると同時に、つまりこれは数百分の１の分担の仕事？と思うと気が楽に（ポジティブ思考）
担当する所は携帯のメニュー機能の所だった。それほどスキル要らないという話だったけれど、全てはメニューから始まり、全てに飛んで帰ってくる所なので、動画やらデータベースやら写真やら音楽やら全ての担当とのやり取りが必要という、陽キャ専用スキルが必要な所だった、まずい。
何が不味いか、各担当と何を話せばいいのか分からないのである。そもそも知識がない。やりとり以前の問題なのだ。よって、与えられたプログラムを注入出来る携帯とPC開発環境と新しい携帯の仕様書を読んで理解する事から始めた。リーダー会議？工数？言われても分からんそんなもん。
うちのメニューのチームは５人だった。年配の人に若い子２人に女性が１人、もうひとりは別の組込みをやってて途中から合流という流れ。広いフロアに１５０人くらいは居たと思うけど、どうも携帯ごとに３、４ブロックに分かれていたようだ。
統括リーダーはこれまたヤクザみたいな人でリーダー会議では大声で怒鳴りつける系で全員が終始ビクビクしているのだが、喫煙室では「別チームの機種がもう終わるからメニューに出来るやつが行くからもうちょい待っとって」とか口調もやわらかくなる。無理相談しやすい場所になっていく。
聞き捨てならない言葉「出来るやつが入ってくる」ここに我が人生の全てをかけることにした。つまり私の習得してきたスキルを全駆使して、リーダーをすげ替えればいいのだ。その人がやってた機種は○○１、僕らがこれからやるのは○○２。要は既存機種のバージョンアップ版なのだ。
C言語を勉強している暇なんて無いぞ。リーダーなすりつけ大作戦の幕開け。同じメニュー担当だったっぽいので、こっちに合流した瞬間に合理性や効率性を説いて、僕はリーダーなんてしたくないオーラをこれでもかと出しながら交代する事に成功した。クビにならんか心配だった。
一ヶ月もすると何となく仕組みが分かってきて、どうも派遣会社同士の席の取り合いみたいな感じになってる。明らかに僕と同じく、よく分かってない人もチラホラいる。偉そうな人はプログラムなんてしてなくて、これはあーだこーだだけ言ってる人がいる。
つまり一切プログラムしなくても生きている人らがいるのだ。蜘蛛の糸のようだ。掴まるしかねえ！と思ったけれど、リーダー交代すると時間も精神的な余裕もとれたので、真面目にプログラムやってみようという気になった。幸いしたのは既存機種のグレードアップ版という事でプログラムは流用だった事。
流用だとコピペでなんとでもなった。メニューの項目が３つ並んでれば、プログラムを見ると３つ並んでる所がある。３つめをコピペして４つめを作れば、そこが増えたのだ。んでちょちょっと４に合わせて変えるだけ。知識無しにコピペ。え、これ大勝利じゃない？コピペで給与がもらえるのだ。
コピペで手取り45万って本気なの？騙されているんじゃないかと思いましたが実際に貰えたのでちょっとビックリです。チームとも慣れてきて聞いてみると「えええええええそんなに？僕16万くらいですよ」と、どうも間に入っている派遣の数やら諸々で決まるっぽい。ここまで違うか、なんて恐ろしい。
だがしかし、コピペでは対応出来ない部分もいろいろと出てくる。そういうのは後回しにした。でもいつ出来ますか？とリーダーが突っ込んでくる。非常にまずい。３をコピペで４を作り、４の画面に行き、戻ると３を選択したままなのだ。４じゃないといけない。そういう細かい間違いが色々と出てくるのだ。
一つ一つの動作する時に目に見えないアホみたいな量の隠蔽データをしょって移動している事に気がついた。移動時に前の状態を持っている所があったのを発見する。色々とやってくうちに、プログラムってゲームブックみたいなもんだと分かってきた。あー、超めんどくさいゲーム。しかも作るほうじゃん！
あまてるは３を押した。4pageに進む。住所録が現れた。どうする？。しかし登録する友達がいない、GAMEOVER。みたいなそんなの。友達は隠蔽されたデータだ。この場合、実は友達いましたなら先にすすめたのだ。この隠蔽されたデータこそパラメータでこれらの値の変動とルールを決める事がプログラム。
隠蔽されたデータの見方がわかれば、なんかパッと瞬間的に何かがひらめいたみたいな神が降りてきて、あー完全理解した（してない）境地に到達した。
理解したからには、ちょっと適当になる。要はしたい結果に導けばいいだけだ。悪いこといってそそのかす詐欺師のように。
次の所に行くには友達3人いる。友達追加してる所どこかな・・どこかな・・わからんぞ、何ページ目だっけ・・どこや・・どこだ。あ、もういいやここで追加してしまえ +2 っと（白目）。そういう力技を手に入れたのだ。他で辻褄があわなくなったら考えよう。先は長い、そのうち見つかるやろ大丈夫やろ
百聞は一見にしかずというか、百見は実践にしかずと言う感じで、多分家で本読んでただけじゃ、なんも分からなかったかもしれない。工数が決まっていて期限区切られ、クビにもなりたくないというので必死で、今ある実際動いている携帯のプログラム中身を紐解いていくほうが理解度が早かったと思う。
なんだかんだで工数内で出来上がり、発売された後にバグ回収などあったのですが、僕の箇所には一つもなくホッと一安心。あんなとってつけだったのに。そんな僕のくみこんだメニュー機能がニ台ほど2006年頃に世の中に出たわけであります。
当時、実は借金まみれで土壇場でしたが、右も左もわからんでも業界内に飛び込んでいけば、、なんとか、、なんとかなると、してみせると、、そういう話でした・・。おしまい。
で、結局ポインターってなんなんだったんだろう
社で「退職訓練」と呼んでいるやつ、本当に便利
退職予定者について、最終出勤日の数日前にいったん各種アカウントを一時的に無効化する。そうすると業務で使っているトークンが無効になったりして、どこに影響が出るかわかる。
しかし、こんなに便利なのに涙が止まらないのはなぜ…
なるほど知見だ
DDDやクリーンアーキテクチャという偶像崇拝を今すぐやめろ
過去30年にわたり、マルウェアの開発環境はC言語やC++、Delphiなどのコンパイラ型言語が主でしたが、近年はPythonなどのインタプリタ型言語によるマルウェアが増加しているとのこと。特にPythonはプログラミング初心者に優しく、簡単に開発でき、ライブラリが充実していることから、マルウェア開発者の注目を集めているとジャクソン氏は語っています。
コンパイル型言語によるマルウェアとは異なり、Pythonのコードを実行するためには実行環境をOSにインストールする必要があります。しかし、PyInstallerやpy2exe、Nuitkaといったツールを用いれば、Pythonを実行ファイルに変換することが可能。また、C言語によるマルウェアよりも、Pythonによるマルウェアの方がプログラムのサイズやリソース消費量が大きくなりがちですが、インターネット回線の高速化やコンピュータースペックの進化などにより、近年はプログラムサイズが障壁になりにくくなっているそうです。
Pythonコードを実行ファイル化するツールが使われてるということか。
MSは元々OSが動けばCPUは何でもいいぐらいのノリだし、ARM対応版のWindowsもすでにある（Surface向け）。
Intelとしては本音ではx86を切り捨てた設計にしたいけど、IA64で失敗したから仕方なくx86アーキテクチャを続けてるだけで、ビジネス的なメリットさえあればさっさと切り替えるんじゃなかろうか。
Torvalds氏のAVX512に対するコメントは、フリー/オープンソース情報サイトPhoronixの記事（「GCC 11 Compiler Lands Intel Sapphire Rapids + Alder Lake Support」）に関するものだ。記事では、次期「GNU Compiler Collection 11」がIntelのAlder LakeとSapphire Rapidsをサポートすることに合わせて、これらがAVX-512命令セットをサポートしていないことを指摘していた。
この記事についてのメーリングリストで、「AVX-512を気に入っていないといいが。GCC11のAlder LakeターゲットではAVX-512は有効ではなく、AVX2のみだ」というコメントに対し、Torvalds氏は、「AVX512が苦しんで死ぬことを望む」と記した。
「AVX512が苦しんで死ぬことを望んでいる。そして、Intelは、魔法のような命令セットを作り、よく見えるベンチマークを出そうと試みるのではなく、実際の問題を修正すべきだ」とTorvalds氏、そして「Intelは基本に帰って、自社のプロセスがちゃんと機能するようにすべきだ。そして、HPC（高性能コンピュータ）など意味のない特別なケースではなく、通常のコードにもっと集中すべきだ」と批判した。
Torvalds氏はさらに、Intelが独占状態を築いたx86全盛期、Intelの競合の方が常にFPの性能が高かったことを指摘し、「AVX-512でも同じことが起きているーー将来もそうだ」と記す。「トランジスタの予算を他のもっと関連性のあることに費やしてほしい。FPの計算であったとしても（それも、AVX-512ではなく、GPUにおける）。あるいは、AMDがやっているように、単にもっと多くのコア（シングルスレッドパフォーマンスだが、AVX-512のようなゴミはなしで）がほしい」とも書いている。「通常の整数コードでパワーの限界に到達したい。動作周波数（memcpyを使うことになる）やコア（使えないゴミはスペースを占有する）を取り除いてしまうAVX-512のようなパワーウイルスではなく」。
「苦しんで死んでほしい」は政治的に許されたワード
pnpmが他と違うのはパッケージの管理方法だ。npmとYarnがプロジェクト毎に別々のパッケージのコピーをインストールするのに対して、pnpmはすべてのパッケージについて単一コピーを維持し、オリジナルインストレーションの参照にはハードリンクやシンボリックリンクを使用している。
pnpm 5.0より前は重複管理がパッケージレベルで行われていたため、同じLodashのバージョンが2回使用されていた場合において、パッケージのインストールが1回で、2つのプロジェクトにリンクされていた。
pnpm 5.0では新たな連想ストレージ(content addressable storage)システムが導入されたことで、個々のファイル間の差異をpnpmがテストできるようになった。その結果として、異なるパッケージ内にイントールされた同一ファイルを列挙して、再利用することが可能になっている。例えば、最新のLodashリリースで変更されたファイルが、300近い全ファイル中の9つのみであった場合、新システムでは、変更されていない大部分のファイルについては、重複の必要を排除している。
ふーむ
Go To 文を使っていいのは
後藤さんだけです。
sudo コマンドを使っていいのは
須藤さんだけです。
192.168.1.1は私のIPアドレスなので使わないでください。
起業して3年位は節税とか含めて起業前の可処分所得が倍以上になったと無邪気に喜んでるんだけど、だんだん同僚や上司もおらずOJTまで含めてインプット機会が無くなり、技術や情報が陳腐化してきて仕事も減り初め、10年近くなるともはや屍のような個人事業者で溢れてるけど誰の目にもつかない(´･_･`)
WEBデザイナーを自称している（た）界隈、こういう事例で満ち溢れていて本当に草も生えない
ミシマでは、1日当たり数件ほどの販売・相談がコンスタントにある。壊れたマシンを抱え「生産ラインが止まった」と飛び込んでくる新規の客は後を絶たない。バブル経済期に設備投資された工場では、設計時点でPC-98をシステムに組み込むことが多く、設備を丸ごと入れ替えない限りPC-98を使い続けざるを得ない。長年ノートラブルだったシステムが突然動かなくなり、「分かる人間がもう社内にいない」と、お手上げ状態で相談してくる現場責任者も増えているという。
工場以外でも、社内の経理システムで使い続ける経営者や、楽曲制作の機器として愛用し続けるミュージシャンなど、「キューハチでないと駄目」とこだわる得意客が少なくない。井口さんは「仕方なく使い続けるというよりも、『このパソコンでないと良い仕事ができない』と、愛着を抱く人が意外と多い」と印象を語る。
工場の制御システムの要になっているという話はよく聞くけど、設備更新できないの本当につらいな
＜性能へのシビアな要求に向き合う。＞
広告システムは扱うデータ量も非常に大きく、常にレイテンシーやスループットに対する高い性能が求められます。その厳しい要求に目を背けることなく性能にこだわり続けることで、広告がユーザーの目に触れるチャンスも広がり、それがプロダクトの成果にもつながります。本当に今の設計や処理方法でよいのか、常識を疑い振り返ることもときには大切です。
＜スピードと品質を両立させる。＞
スピードと品質のように、本来トレードオフの関係にあるものを両立させて欲しいと言う要求はよくある話です。そんな時、今作ろうとしているものが本当に必要なものなのかをエンジニア一人一人がきちんと考えてみてください。無駄を省きシステムをシンプルな状態に保つことを心がけましょう。目の前の課題を少し違った角度でとらえてみることで、一見、相反しているように見える要求も実は両立できたりするものです。
＜経験よりデータを。直感より分析を。＞
リリースした機能が期待通りの効果を出せているのかを見極めるのは意外と難しいものです。実は予期せぬ別の要因によって効果が出ているように見えているだけかもしれません。データに向き合い、要因を見極め、自分たちのしていることをきちんと理解しながら進んでいくことがアドテクスタジオのエンジニアには求められています。
＜有益な情報を伝えることが広告である。＞
広告は邪魔なものだと思われがちですが、有益な情報をそれを必要とする人に的確に伝える技術力があればそれは価値あるものに変わります。広告システムの先には常にユーザーがいること、その人たちにどのように情報を伝えるべきなのかを常に意識して開発を進めていくことが大切です。
Apache Flinkはオープンソースのストリーム処理フレームワーク。JavaとScalaで作成された分散ストリームデータフローエンジンを持ち、Kubernetes、Yarn、Apache Mesosなどのリソース、HDFS、Amazon S3などのストレージを利用できる。
『未来をポジティブに』
悪い側面は当然目につくことはあり、それは仕方のないことだ。 そんなときに愚痴を言うのではなく、どのようにすれば良い側面を実現できるのかを考えるようにしよう。 頑張れそうな言葉を使っていこう。 ネガティブな表現をしてしまうとそこで思考が止まってしまう。 ポジティブな表現をすることで未来を作りだそう。
『失敗を称え、失敗に学べ』
我々は不確実性の高い課題に立ち向かおうとしている。 そんな中で失敗が出てくるのは当然だが、その失敗はチャレンジから生まれていることを理解し、称えよう。 そしてその失敗を価値あるものとするために素早く振り返り、学びを持とう。 ただし失敗するにしても大きな失敗はしたくない。 致命的なダメージを避けられるような仕組みや転び方を考え、チャレンジし続けられるようにしていこう。
『ムダ排除に全力を』
システム開発の現場で働いていると、どうしてもコントロールしきれない不確実性のあるものが出てくる。 そんなとき、どうしても頑張らなければいけない状況で踏ん張ることはもちろん大事だ。 しかし何度も繰り返すような仕事は自動化させるべきだ。 今日やる必要のない仕事は今日じゃない日にやるべきだ。 だから優先順位をつけて本当に必要なことを取捨選択していきたい。 結果、今日やるべきことだけを終わらせて定時に帰れるような働き方をしていこう。
『チームであれ』
一人で仕事をしているわけではなく、我々は複数人で同じ目標に向かって進んでいくチームでありたい。 そのためには協力が必要になる。 周りを見渡そう。 HELPを求めている人がいたら快く支援を申し出よう。 HELPを求めやすい雰囲気があるチームでもありたい。 そのためには情報の透明性も大事だ。 だから各自が自らの仕事の状況、気づき・学び、知見、何らかの情報、人となりなど、アウトプットを進んで行おう。 そして共に成長することの喜びや楽しさを得ていこう。
『自らがチームの主体であれ』
誰かによって決めてもらわないと物事が進まないようなやり方で仕事はしたくない。 メンバー各自が自分の考えを持ち、それに基づいた自発行動を取れるように動きたい。 そのためには権限委譲も必要に応じて進めていこう。 結果、スピード感を持って行動できるチームになろう。
Broaden Yourself; 己の限界を広げるべし。
プロフェッショナルとしての知識・技術の習得に限界や終わりはない。常に最新のトレンドから枯れた知見まで幅広く意識を向け、実際に手を動かしながら己のものとすべし。
Prepare Yourself; 次の機会に万全であるべし。
機会を掴み取れるのは、それに備えている者のみである。来たるべき機会に何が必要か、何が期待されているかを考え、常に万全であるべし。
Be Positive & Proactive; 常に肯定的・主体的であるべし。
受け身であること、否定的に捉えることは誰でもできる。顧客への価値を最大化するため、次に何をできるか、よりよくするためにさらに何ができるかを常に考え、自ら行動すべし。
Know Yourself; 己に求められているもの、 そこまでの道筋を知るべし。
己が何を求められているか、求められているものまでの道筋はどうか、そして己は今どこにいるかを常に知り、求められているものを完遂すべし。
Stay Humble; 常に謙虚であるべし。
他者は異なった立場や文脈、背景を持っており、自分と全く同じではない。相手の立場、文脈を尊重し、かつ自分の伝えようとしていることを相手がどう理解しているか踏まえつつ行動すべし。
Share Everything; 己の知見は遍 (すべから) く共有すべし。
己の学んだ知見の価値を決めるのは己ではなく、その知見に接する者全てである。共有する前に己でその価値を過小評価せず、遍く共有すべし。
行動哲学
- HRT（謙虚、尊敬、信頼）
- 自律的に動く
- 暗黙知を作らない
- 許可を求めるな謝罪せよ
- 官僚的にならない（「○○さんの許可を得ないとできません」はNG）
- 技術的な間違いは躊躇せず指摘
- 3度同じ事を繰り返す時は自動化
働き方
- リモートワークを妥協しない
- 非同期に働く。フロー状態の同僚を邪魔しない
- KPT：定期的に自分たちのやり方をアップデートする
オープンさ
- 自らの仕事（プロセス・成果）をオープンに
- 情報は閉じ込めてはいけない
- どこにあるかわからない / 誰も読んでないドキュメントには価値はない
設計と実装
- 12 Factor App
- KISS and YAGNI: 過剰に設計しない
- Dirty Hack より中長期的に維持可能なシンプルな仕組み
- コピペせず時間をかけて堅牢なコードを書け
- 複雑なコード、Dirty Hack の積み重ねは時間と共に周囲の人間のモチベーションを蝕む
- DRY
チャレンジ
- 新たな技術をキャッチアップしプロダクトに組み込む
- 技術ナレッジを発信する
- 未知な領域へ取り組む意欲をもつ
- 自分のスキルマップを分析しアップデートし続ける
プロフェッショナル
- 本質的な課題にフォーカスする
- スケーラブルな設計をする
- リーダブルコードを書く
- より速いレスポンスを実現する
- セキュリティをネガティブチェックする
オーナーシップ
- ルーズボールを自ら拾う
- コードを共有資産と認識し、リファクタリングやレビューをする
- バグを憎んで人を憎まず
- 提案ベースの相談をする
- 組織の垣根を超えて能動的にコミュニケーションをとる
正しい設計を保つことを目指した結果変更箇所が少なく済むのは悪くないどころかむしろ素晴らしいことですが、「正しい設計を保つこと」と「変更箇所を減らすこと」が対立したときに後者を優先しているとアレ、みたいな話です
「ある機能を実装する際に、常に変更するファイル数が最小になるような方針を採用する」というのを10回くらいやると立派なレガシーコードが
すごくよくわかる
（1）他人任せのキャリアプラン
人事機能不在のSES企業において、ITエンジニアのキャリアプランなど誰も考えてくれないし、支援もしてくれない。ITエンジニアが育つか育たないかは、ずばり「運次第」である。
良い案件や、良い常駐先に恵まれればキャリアアップやスキルアップのチャンスを得ることができる。スキルや徳のある人と出会え、新しい技術にチャレンジする機会があり、オフィス環境にも恵まれ、ITエンジニアとしての人権がある働き方ができればラッキーだ。
一方、ハズレを引くと目も当てられない。人権がないかのような環境で、モチベーションも主体性も思考力も奪われ、延々と下働きだけをこなす。下手をすれば、1年、2年、あるいは3年以上を無駄に過ごすことになる。当たりを引くか、ハズレを引くか。その差は大きい。いわゆる「案件ガチャ」「常駐先ガチャ」である。
おのずとキャリアプランは運任せ、他人任せになる。
クラウドの技術を身につけたくとも、常駐先が「オンプレミス」といえば「オンプレミス」の環境に身を置くしかない。それどころか、GitHubやSlackすら使わせてもらえない。進捗管理や課題管理も、Excelどころか常に口頭。技術力どころか、基本的な仕事のマネジメント能力を伸ばす機会もどんどん奪われていく。
（2）技術／知識向上も自助努力
多くのSES企業における技術／知識向上は、基本的に自助努力である。「未経験者歓迎」などとうたっておきながら、ろくな研修も資格取得の支援もない。どんな知識を身につけておくか？ どんな技術を学ぶか？ すべて「自分（あなた）次第」なのだ。
勉強会のような取り組みを行っているSES企業もある。月に1回設定された「帰社日」がそれだ。その日は、半ば強制的に全社員が自社に集められ（常駐先にそんたくし、定時後であるケースが多い）、社員同士の交流と勉強会が行われる。しかしその勉強会の中身たるや、お偉いさんの講話だったり、プロジェクト事例の紹介だったりする。おおよそITエンジニアとしての知識習得にも技術研さんにも程遠い。そもそも、普段まるで接点のない他の常駐先の人たちの、全く違う案件の話を聞いたところで身が入らない（と少なくとも現場のITエンジニアは思っている）。
（3）技術を生かす機会もない
それでも成長意欲の高いITエンジニアは、学習に積極的である。職場環境やカルチャーのせいにせず、自助努力で新たな知識や技術を吸収する。
しかし次なる壁が立ちはだかる。せっかく習得した知識や技術を実践する機会がないのである。保守的な職場であればあるほど、新しいことをしようとしない。
「顧客や営業に言われたことだけをやればいい」
こう、現場の管理職からくぎを刺される。
さらには「そんなことして何になるの？」「それ、意味があるの？」と冷ややかな言葉を周りの人たちから浴びせられる。やがて、自分だけ頑張っているのがばかばかしくなり、学習意欲が高い人も「学ばない人」「物言わぬおとなしい人」と化していく（あるいは学んでいることを隠すようになる）。
筆者はSES企業に勤務する人でまともにマネジメントができる管理職にお目にかかったことがほとんどない。ベテランとおぼしき管理職でも、驚くほどマネジメント能力がない。部下を悪気なく傷つけたり、スポイルしたりする。まれにできる人もいるが、たまたまセンスがあるか、あるいは前職できちんとしたマネジメントをしてきた人だ。マネジメントできない管理職の問題を挙げる。
（i）部下を育成できない、評価できない
客先常駐型のビジネスモデルでは、客先や風向きによって求められるスキルも経験も異なる。よって、自律的な育成計画を立てにくい側面もあろう。
おのずと育成計画も行き当たりばったりになる。さらには「習うより慣れろ」のOJT（オン・ザ・ジョブ・トレーニング）一辺倒になりがちである。問題はそれだけではない。
他人を育成できない。自助努力だけで、場の要求に応じて技術を身につけてきた人であればあるほど、その過程を言語化したり他人に伝えたりするのが苦手である。技術のプロであることと、育成のプロであることは別物だ。
ガントチャートあるある
ガントチャートを今の動きの早いプロジェクトで使ってみるとどうなるか。大体、下記のようなパターンになってしまいます。
- 「何をやるか」が決まっていないのになぜか計画前に納期だけ決まっていて、「死守だ！」と言われてそれに間に合わせる計画を作成することになる
- 納期がカギなので、ガントチャートを作って逆線表（〆切から逆算した計画）を作る
- 何となく形になりそうなのでプロジェクトを開始する
- プロジェクト開始後、想定外のトラブルや計画変更が頻発してガントチャートの更新に膨大な時間がかかる
- 更新に時間がかかるため、「今どうなっているのか」がわからなくなる（みんなが常に「過去の計画」を見てプロジェクトをやるようになる）
- エクセルなどで作成していると、どれが最新版なのかが分からなくなってより混乱する
- 誰もガントチャートを見なくなって計画がバラバラになってトラブルが頻発する
- プロジェクト炎上
みたいな流れが多すぎるので、ガントチャートは作らない方がよいまである。
今回発表された新機能は、Docker DesktopのコマンドラインからDocker Composeコマンドを用いてAmazon ECSへ簡単にコンテナアプリケーションがデプロイできる、というものです。
kubernetesを頑張りたくないレベルのシステムならもうこれでええのでは感あるな
昔は同じコードを複数箇所で書くのは冗長で良くないことだと思ってたけど、コンテキストの境界ごとやレイヤごとに定義しないと色んな意味を持ちすぎて辛くなってくるんやなって大量にクソコード書いて学んだ。。
なんでも共通化すればいいというものではないのだ
SESで仕事してた時は、客先常駐で会社やプロジェクトが入れ替わるので、プロジェクトに参画した直後にどれだけ早く現場の知識や文化を吸収できるかが勝負だと思ってたので、特に最初の数ヶ月は謙虚になんでも質問して、メモして、実践してましたね。
同じくSESで仕事をしていた時期があったけど、数ヶ月単位でプロジェクトが変わるのにそのプロジェクト固有の知識を覚える意義（コストに対するメリット）が見いだせなくて適応障害一歩手前まで行ってた（特に金融や保険など知るべき前提知識が莫大な場合特に）。
長くプロジェクトに残れないのは自分のスキルの問題もあったけれども。
結局自分はSESは絶対に嫌だということで内製でやってる会社に転職することを選択したのだった。
結論から述べると、2020/07/12現在の最新バージョン（v3.0.1）のShaka PlayerではFairPlayは再生できないので注意されたい。
確認したバージョンはv3.0.1。
このバージョンではHLSマニュフェストファイルのKEYFORMATがコメントアウトされており、FairPlayのKEYFORMATは絶対にマッチすることがない。
この為、このバージョンを利用する限り、Shaka PlayerではFairPlayで暗号化された動画を再生することはできない。
FairPlay対応用と思われるブランチが存在することからいずれはFairPlay再生にも対応するつもりはあるようだが、こちらは数年単位で動きがないので正確なスケジュールは不明である。
備えよう。
「プルリクでの差分レビューの価値は薄い。マージ後の全体現状が全てで、コードは全部読んでて当然」を基本スタンスにして、適用できるときはそれでメインライン一本道戦略をとってる。
PRレビュー無しはレビューをしないという意味じゃなく、常時マージ後全体のレビューができなきゃやっちゃいけないと思ってる。で別に不可能でもない。とはいえ要求水準は高いんだよね・・・
PRでの検疫に価値がないとは言わないんだけど、検疫はあくまで検疫だし、検疫的なPRレビューで運用が硬直されたチームはメンバーのスキルもそれに最適化されると思ってる。私は現状に合わせる安定指向だけど、現状ぴったりよりは「将来こうありたい」に半歩踏み出した運用をとることにしてる。
要は「常にコードベース全体を自分ごとにしてほしい」であって、差分を見る必要がある時は各々の判断で勝手に見てほしい。差分レビューはそれを阻害するんだ。
当然必要ならいつだって安定指向プロセスに切り替える。そんなの当たり前…。
確かに細切れのプルリクとかレビューしんどいしなぁ
Googleと、「Ubuntu Linux」の開発元であるCanonicalは、GoogleのUIフレームワーク「Flutter」を用いてLinuxデスクトップ向けのアプリを開発できるようにする取り組みを続けている。この協力の成果として、開発者がFlutterでLinuxデスクトップアプリを開発し、Canonicalのアプリストア「Snap Store」で公開できるようになっている。
こんなんOSからは一切検知できないからめっちゃやべぇやんけ
READMEを見る限りかなり簡単に使えそう
RDRAの要件定義だと、画面の"完全”な一覧や画面レイアウト、テーブルの一覧やテーブル定義までは作らない。
何をなぜ作るかの認識合わせという基本目的では、画面の一覧と項目定義、テーブル一覧とテーブル定義は、粒度が小さすぎる。そのレベルの検討の前の、認識合わせがRDRAの要件定義の目的。
・手作業であること
自動化されていない多くの仕事。スクリプトの実行を手作業で行う場合も含む。
・繰り返されること
トイルとは繰り返し行われる作業を指す。ある作業をするのが初めてだったり、新しい解決策を生み出しているのであればそれはトイルではない。
・自動化できること
機械的に置き換え可能な仕事はトイルである。逆に人間の判断が欠かせないものはトイルではない。
・戦術的であること
トイルは戦略的であったり予測に基づくもの（proactive）というより、割り込みで始まり何らかの対応を強いられるもの（reactive）である。例えばページャーのアラートへの対応はトイルである。このような仕事を完全になくすことはできないが、最小限になるよう努力する必要がある。
・長期的な価値を持たないこと
あるタスクの後でサービスが同じ状態だとすれば、それはトイルといえる。逆にそのタスクによって恒久的な改善が加えられれば、それはトイルではない。
・サービスの成長に対してO(n)であること
サービスのサイズ、トラフィックの量、ユーザー数などに比例してスケールするようなタスクはトイルである。
環境:
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
snapでインストール
snap install --devmode --beta anbox
確認
$ snap info anbox
name: anbox
summary: Android in a Box
publisher: Simon Fels (morphis)
store-url: https://snapcraft.io/anbox
contact: https://anbox.io
license: unset
description: |
Runtime for Android applications which runs a full Android system
in a container using Linux namespaces (user, ipc, net, mount) to
separate the Android system fully from the host.
You can find further details in our documentation at
https://github.com/anbox/anbox/blob/master/README.md
commands:
- anbox
- anbox.android-settings
- anbox.appmgr
- anbox.collect-bug-info
- anbox.shell
services:
anbox.container-manager: simple, enabled, active
snap-id: Nr9K6UJaIOD8wHpDEQl16nabFFt9LLEQ
tracking: latest/beta
refresh-date: today at 00:33 JST
channels:
latest/stable: –
latest/candidate: –
latest/beta: 4-56c25f1 2020-01-02 (186) 391MB devmode
latest/edge: 4-6a3f886 2020-03-27 (191) 391MB devmode
installed: 4-56c25f1 (186) 391MB devmode
インストールしといてアレなんだけど、まだ実用レベルじゃないぽい
単にPCディスプレイで操作（表示）したいだけならChrome castした方がよさそうかな？
繰り返しの毎日がイヤなんです
（中略）
こういう勘違いしとるヤツには「繰り返しじゃない仕事教えろ」というと効果的。だって、ないもの。次いで「繰り返しじゃない仕事をしたいんじゃなくて、繰り返しの中で違いを生み出せない状況に不満があるんじゃないのか？」と聞くと大体正解、ご名答。そういう人は転職しない方がいいです。また同じ勘違いするから。
この仕事向いてないと思うんですよね
確かに向いてないかもしれんね。でも、誰と比べて？ これ、意外と即答できんヤツが多い。
実は、向き不向きは他人が決めることなんですよ。自分が決めることじゃない。自分で決められるのは好き嫌いであって、どうもこれを向き不向きと勘違いしとるのよね。おめーがやりたくねえだけじゃねえの？