「プルリクでの差分レビューの価値は薄い。マージ後の全体現状が全てで、コードは全部読んでて当然」を基本スタンスにして、適用できるときはそれでメインライン一本道戦略をとってる。
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した方がよさそうかな？
繰り返しの毎日がイヤなんです
（中略）
こういう勘違いしとるヤツには「繰り返しじゃない仕事教えろ」というと効果的。だって、ないもの。次いで「繰り返しじゃない仕事をしたいんじゃなくて、繰り返しの中で違いを生み出せない状況に不満があるんじゃないのか？」と聞くと大体正解、ご名答。そういう人は転職しない方がいいです。また同じ勘違いするから。
この仕事向いてないと思うんですよね
確かに向いてないかもしれんね。でも、誰と比べて？ これ、意外と即答できんヤツが多い。
実は、向き不向きは他人が決めることなんですよ。自分が決めることじゃない。自分で決められるのは好き嫌いであって、どうもこれを向き不向きと勘違いしとるのよね。おめーがやりたくねえだけじゃねえの？
観察してみた結果、すごく単純で、他人や、他人のアイデアを否定しないことが究極のポイントのようです。「えーそんなんやったら違う意見言えないやん」と思うかもしれませんがそんなことはありません。
否定されたときに心がつらくなる原因としては、「自分が否定された気分になる」ということが大きいと思います。私の職場のコミュニケーションを見ていると、日本にいるときによくあった「お前は間違っている」とか「それは間違っている」という発言は全く聞きません。
多分言ったら相当失礼な人と思われるかもしれません。ちなみに、日米文化の専門家のㇿッシェルカップさんが言っていたのですが、日本から来たマネージャが、パワハラで訴えられることが多いという話があって、このあたりが原因の一旦かもしれません。意外かもしれませんが、アメリカでは敬語はないですが、人に何かを依頼するときは相当丁寧な言い回しをします。
こういった反対意見を言うときや自分の意見を言うときに頻繁に出てくるフレーズが、「In my opinion」です。日本語でいうと、「自分の意見では」とか「自分の意見を述べさせてもらいますね」みたいなニュアンスです。
このノリで話すと、たとえ相手のアイデアと正反対の意見であっても、言われたほうがあまり「心にぐさっとこない」感じになります。
DIってDIするしか解決策がない
もしくは、DIしないとやってられない状況だから使ってるだけで
DIがないとアプリケーションが作れない つまり必要条件？ではないよね
そりゃまぁ
例えばPythonはわざわざDIを使わなくてもモジュールの差し替えが簡単にできるので、あえてDIを頑張るモチベーションに乏しいので大抵のPythonプロジェクトではDIは使われていない。
ホリエモンが「偏差値60以上の人間は自習できる」と言ってたけど、まさにその通りで不足しているエンジニアの層って教育しなくても自習できる層なんだけど、プログラミングスクールに通う層って、どう見ても平均偏差値50を切ってて教えてもらったことしかできない傾向あるんだよね。。
それ以上いけない
人間は単純記憶をすぐ忘れる生き物なので、(何の節約か知らないけど)差分を最小にしたコード変更から出てきた変則仕様は、いくらドキュメント化しても忘れます。どれだけ重厚になろうが、やるべきことを徹底してやって、不整合ないモデリングを追求したほうが、後で見て簡単になり安上がりです
円周率の任意の部分を 10 桁見てそれを半年後に言える人は少ないけど、もしこれがドラゴンボールのキャラを登場時期順に言えだったら、これから読む人でもたぶん 20 人余裕です
人間には情報から合理的に前後を連想をする能力があるし、なんなら間を補完さえできるいっぽう、不合理でランダムな決定から生まれた仕様は、そのドキュメントのありかさえも忘れます。定期的に「なんでこここうなってるんだっけ」「しらんがなそんな経緯」が起きます
早く動く結果だけを得ようとする人の学習が進まないのは、単にやる気の問題なだけではなく、この罠で自縄自縛をしているのかもしれません。自分の書いたコードがどんどん難しくなっているのに、早く結果を出そうとして、泥沼スパイラルに陥ってしまうかたち
ついか: そうは言ってもビジネスのサイクルってもんが ← そのとおり、なので、ここのギャップを認識して、突貫のハリボテとハリボテの鉄筋化のバランスを取るときの概念が技術的負債。あとで時間さえあれば完済できるとわかってる人だから借入ができる、という認識です
これは確かに
エンジニアリングの世界で経験値がまだ低いのに他責思考が強すぎる人は正直ろくなもんじゃないというか仕事にならん上に育たないんですよ。自分の力（がないところ）を直視できないから。びっくりするくらいに。
これは本当にそう。
20代のうちに適性が無いことを悟ってジョブチェンジできればまだいいのだが、たまにしぶとく居座る者もいる。
で、そうやって居座り続けた者がいつの間にか使える人材に育っているかというと、そんな奇跡が起こるはずもなく。
シンプルに社内のお荷物おじさんとして新人にさえ蔑まれることになる。
彼らの社内における扱いは悲惨であるし、その人生もまたそうだ。
新しい技術を紹介する時に、既存技術との違いを強調することになる。
しかし違いの中には本質的でないものや、効果が未検証な違いがたくさんある。
だから新しい技術の登場直後の説明は、後から振り返ると怪しげな内容も多い。
オブジェクト指向プログラミングは、その典型。
おそらくオブジェクト指向プログラミングの本質的な特徴はデータ抽象。あるいは型(値の種類)に注目したモジュール化。
実装を継承した差分プログラミングは本質ではなかった。
オブジェクトの不変性があたりまえになった現在は、内部状態の変化のカプセル化すら、本質ではなくなっている。
GUIが本質ではないのは昔から言われていた。
むしろオブジェクト指向プログラミングの発展の歴史から見るとGUIと関連づけたのは、失敗だったと言える。
しかしながら、新しいものは優位性や違いを明確にしないと無視・忘却されてしまうので、当時はそうするしかなかったのかもしれないな
Win/Learn/Tryとは、スプリント内の出来事をWin/Learnに分けてチーム内に共有し、新たなTryをチームで模索するフレームワークです。
Win
そのスプリントで出した成果等を報告します。Winと言われてもピンと来ない場合はDone/Deliverと言い換えるとわかりやすいかもしれません。レトロスペクティブで利用されることの多いKPTでいうとKeepに近い項目ですが、Keepは少し抽象度が高くてイメージしづらいですし、よりポジティブで具体的な内容が出しやすい点でWinの方が気に入っています。
また、メルカリでは目標設定にOKRを採用していますが、OKRイベントにおけるWinセッションのようなニュアンスも取り入れた結果、Winというワードにたどり着きました。
Learn
そのスプリントでの学びをチームにシェアして、以降のスプリントに活かします。後述しますが、Fun/Done/LearnのLearnのアイディアをお借りしてきました。KPTでいうとProblemに近い項目ですが、問題ではなく学びにフォーカスすることで、前向きな気持ちで課題に向き合える点がいいなと感じています。
Try
WinやLearnから抽出された課題やチャンスに対してチームとしてどういったアクションを取るかのアイディアを出します。KPTのTryと同じ項目ですが、KPTより深堀りしたり抽象化をしたりしないと(特にWinからは)Tryにしづらいので少し難易度は高いです。
突然ではありますが、このたびスラドおよびOSDN（OSDN.net/OSDN.jp）の運営会社である株式会社アピリッツを退職することになりました。書類上は7月中旬まで同社に在籍していることになっておりますが、いわゆる「有休消化」という扱いで、6月30日が最終出社日となっています。ここスラドには「編集長」という立場で関わってきましたが、退職に伴ってその肩書きもなくなります。読者の皆様、長らくスラドをご愛読いただきありがとうございました。
また、Googleの広告配信ネットワークではほぼリアルタイムに広告掲出回数やクリック数といった成果を確認できますが、これまで表示されていた成果の数字が突然「なかったこと」にされるといったこともたびたび発生しています。Google側は不正なアクセスを集計から外したとしていますが、何が不正なアクセスなのかという説明はありませんし、掲出回数に関しても、別のデータを元に集計した数字から乖離することは珍しくありません。しかし、これらに関しては、Googleの言っている数字をそのまま受け入れるしかない状況なのです。
検索によるトラフィック誘導に関しても、アルゴリズム変更によってGoogle経由のアクセス数が突然1、2割減るといったことが頻繁にあります。その後アクセス数が戻ることもあったり、逆に突然アクセス数が増えることもあります。もちろん、秀逸・有益なコンテンツはより発見されやすくなるべきだという原則に関しては賛同します。しかし、Google検索の結果は現実にはさまざまな方法で操作が可能であり、そういった手法への対処のための突然のアルゴリズム変更や「Googleの基準」の変更の巻き添えを受けてコロコロと変わるGoogleによる誘導数に一喜一憂する、といった状況には大きな不満がありました。
こういったGoogle依存とも言える現状から脱出するためにはGoogle以外の収益源を模索するしかありません。しかし、残念なら編集長として私個人レベルではその道筋をつけることはできませんでした。これが、私が退社を決めた理由の1つです。
Googleさんはなぁ...
設計の悪い習慣
- 均一化・画一化にこだわる
- 一度決めたらそれ以上の改善をしない
- 表面的な共通性にこだわる
- 視野の狭い簡素化にこだわる
- 計算資源が高価だった時代の設計習慣を捨てられない
SIer さんに発注する立場も経験しているけど、正直なところほとんどの SIer さんはこっちがお願いしたことに対して見積や提案をくれるけど、こちらのビジネスを考えて提案なんかしてくれないわけ。んで、僕もそれで構わないと思ってるし、ビジネスを考えるには発注する側の仕事なんですよ。
でね、同じく発注する立場にいる人が「もっとウチに適した提案しろ！」とか偉そうに言うわけ。まあ、そりゃ怒るよね。だってそれは偉そうに言っているあなたが考えることなんだから。そんな勘違いして恥ずかしくないのって。
もちろん、一緒になって考えてくれて、他社の経験とかからアドバイスをしてくれる SIer さんもいるんだよ。そしたら、そうやって助けてくれたことに対価を払いたいじゃない？
でもね、「なんで何も作ってもらってないのにお金を払うんだ」とか言い出す人もいるんだよね。残念ながら。
でもそうした支援は自分たちに必要だと思っているんだよ。だから、社内でどうやって一緒に考えてもらうためのお金を引き出すかを考えるわけだけど、本来であればこの考える時間やプロセスは発生しないのが健全だよね。
僕も周りだけかもしれないけど、成果物至上主義と言うか目に見える成果物や、目で見て分かりやすい人日工数とかでしか評価できない文化や仕組みがあったりするんだよな。
でも発注側として本当に必要なのは知識だったりするんだよ。なぜか、その知識を提供してもらうことに対して対価を支払えないの。
その代わりにね、自分で勉強しろとか言うんだけど、そうなると時間もかかるし、結局社内工数を考えると結構な費用になるんだよ。
社内にナレッジを残すためみたいなもっともなことを言い出すんだけど、先人から体系立てて学んだ方が圧倒的に理解が早いんだよね。
クラウドサービスになって SaaS とかになるとさ、利用する側が最初に必要になるのは開発されたアプリとかではなくて、クラウドサービスを利用したり運用したりするための知識やノウハウだったりするわけ。
その知識とノウハウの取得にお金を払える企業は早いよね。と、以前の自分を振り返る。
みたいな社内調整みたいな仕事ばかりしてるので、僕自身に特別高度なスキルが身についていないのがあるあるだ。
社内調整や社内政治にばかり詳しくなって、他の会社じゃ使えないスキルばかりを身につけている。
「もっとウチに適した提案しろ！」とか偉そうに言う出すのはIT業界あるあるだけど、更にやべぇなと思ったのはそう言われた元請けがn次請けのエンジニア（自分）にそのまま「意見を出せ」と振ってきた時。
知らんがな以外の感想が無かった。
Google ドライブをつかいはじめたとき「ディレクトリが分かりにくいな」と思っていたんだけど、これは「人間がディレクトリというものを意識する必要はない」という意図にもとづくデザインなのかもしれない。
ファイルシステムではないけど、Scrapbox なんかもツリー構造を排除している。
そんな気はするけど、それでもディレクトリから解脱できてないよね
ヤフーは2020年6月29日、信用スコアサービス「Yahoo!スコア」を8月31日で終了すると発表した。個人利用者向けの機能開発やパートナー企業向けのサービス開発も終了し、同スコア作成に同意した利用者のスコアについては8月31日までに削除する。2019年6月に発表した後に利用者からの反発を招き、「利用者に対してスコアに応じた特典を提供する」という当初想定していたサービスを始められないまま幕引きとなる。
社内でも無理筋という話になったんだろうか
都内のITスタートアップで働いてる者です。
何社か関わってきたけど、人事、採用が下手すぎて組織崩壊してる会社多すぎるなぁと思ったので命令口調でメモ。
■とりあえずミッション、ビジョン、バリューを設定しちゃう
「どこの会社も設定してるから...」と形式的にミッション、ビジョン、バリューを定義している会社は１００％失敗してる。
”ミッション、ビジョン、バリューが必要”というムードを誰が作り出したのかは知らないが、流されるな。
組織の状況や今後の運営から考えて必要なら定義すればいいし、そうでなければ別に定義しなくても構わない。
別にそれ以外の方法もたくさんある。
いずれにせよ、口に出すのが恥ずかしいイキった横文字をミッション、ビジョン、バリューにするのはやめとけ。
■「1年後に100人の組織にします！」とか言っちゃう
シリーズBとかCらへんの調達目処がたってくると、こういう目標を立てちゃうCEOがいるが愚の骨頂。
とりあえず落ち着け。
ビジネスが100％伸びる保証はどこにもないんだから、舞い上がるな。浮かれるな。
状況に応じて必要になったタイミングで必要なポジションの人を採用すればいい。目標数とか決めるな。
VCから「もっとドライブさせろ」とか言われても気にするな。人増やしてもドライブするわけじゃあない。
■経歴だけで判断をして採用してしまう
コンサル出身とか元リクルートとかだけで判断して採用をするな。
アク●ンチュアとか、デ●イト出身でマトモな人間なんて一握りだ。経歴なんて全く当てにならない。
実務能力があるか、組織にフィットするかの２つが全てなんだからこの２つを見抜くことだけに全力を注げ。
ちなみに経歴だけ立派で実務能力のない評論家みたいな人間を採用してしまうと、他の社員に悪影響が出て、優秀な社員はどんどん離脱する。
それでもいいなら好きにしろ。
■計画性なく未経験者を採用してしまう
思いつきで未経験者を採用するな。
特にエンジニア、デザイナーの未経験採用は要注意だ。
求職者側が玉石混交だとかそういう話はおいておいて、会社側がノリで採用しようとしてないか胸に手を当てて考えてほしい。
社内で受け入れ準備、覚悟を決めていないのに「若手ほしいよね」みたいなノリで採用するのだけは本当にやめておけ。
採用される側もする側も最終的に不幸にしかならない。
入社後に教育する体制はあるのか、新規案件で逼迫してもそこにリソースはあてられるのか、その覚悟をしてから未経験採用を考えろ。
■先入観だけで採用要件を決めてしまう
採用が下手な会社は人を見る目がないのに加えて、採用要件がお粗末だったりするから手に負えない。
前にいた会社はシリーズBの調達後に営業を増やすことになったのだが、「営業にITリテラシーいらないでしょ」という方針で採用活動をした結果、ゴリラみたいな営業が立て続けに入社することになった。
入社したゴリラ達は当然ながらSlackの使い方にも慣れず、スプレッドシート関数も使えず、Misocaで請求書をつくることもおぼつかず、何度説明してもHubSpot使えない、みたいな始末。
リテラシーの高い別の営業マンがゴリラ達の代わりに入力業務を引き受けることになり、嫌になって退職。
あとには大量のゴリラと人件費だけが残ったという地獄みたいなことが発生していた。
実際の業務から採用要件を定義してればこんなことにはならない。
めちゃくちゃ簡単なことなのに、世の企業のほとんどはこれができていない。マジで理解に苦しむ。
■組織運営がうまくいかないと「組織の壁」「成長痛」を言い訳にする
組織が崩壊すると、ダメな経営陣は問題を直視せず逃げる。
更には、昔からいたメンバーが大量離職して経営陣への信頼が揺らいでる残りのメンバーの前で
「30人、50人、100人の組織の壁ってあるから。どこも同じ問題起きてるよ。」
「これは成長痛です。つまり伸び代があるってこと。」
とか言っちゃったりする。
この発言をしたスタートアップから、その後に人材流出が止まったケースを見たことがない。
シリーズB、Cあたりの会社で、優秀な人がどんどん抜けて、優秀じゃない人をどんどん補充して、人数は変わらないけど組織としての戦闘力は半分以下になってるみたいなケースはかなり多い。
そうなりたくないなら事業だけでなく組織とも向き合え。
まあダメな人には響かないから無駄だと思うが、以上だ。
そういう経験値が少ないからスタートアップなんだよなぁ
ビジネスロジックのwikipediaの記述が日本語と英語で逆になっている。
日本語版ではビジネスロジックはデータベース上のデータの処理手順と説明。
英語版では、ビジネスロジックはビジネスルールに基づく判断の記述で、データベース操作の詳細とは対極にある、と説明している。
マジか
よくわからないこと
「前任者がドキュメントを残してないので、まったくわからない」って話
ソース コード読んだらわからないか？
趣味でGithub上のそ大きいプロジェクトのソースコードをドキュメントを一切見ないでソースコードだけ読んで解析する事が度々あるから↑の気持ちがよくわからない
どう動いてるかはソース見りゃわかるけど、何でそうしてるかはソースだけじゃ分からないことが多いからなんとも。
結局、考古学的な分析が必要になってしんどいし、自分は楽しくない。
まぁ、そういうのが楽しいなら自分の代わりにやってくれる人がいるという事なので、それはまぁ。
これは確かに
アプリを操作するより何か機械を操作する毎にセンサーに情報が飛ぶIoTの方が農業や工場にマッチしていたのが答えではありそう。
作成するコンテナの定義に、docker-compose.ymlをそのまま使うこともできるので、コンテナ定義の設定が一元管理できて嬉しい :smiley:
docker-compose,yamlがそのまま使えるのか
これはお手軽。
ドメインモデル図がER図の違うところは、
・ビジネスサイドの人と一緒に一緒に更新していく
・DBの話ではなく、現場の人が認識するルール/制約を落としていく
というところかなぁ。逆にいうとそれくらいしかないかもしれない。だから、そんなに難しくないんですよ、ほんと。
ER図（というかDB設計）だって一緒だと思ってたのですがそれは
それぞれ適切に保存しましょうって話を昨日した。
DBには事実を。
アプリケーションにはロジックを。
Viewには情報を。
そして責務を適切に分けた上でやり取りするインターフェイスをしっかりと決めることが大事なんだよな。
持続化給付金と官製 JV と電通の件でよくわかったんですが、 IT 業界でふつうになっている多重下請け構造とはやっぱり「不道徳で非難されるべきもの」と一般人は考えてるんだよな。忘れがちなこの事実を改めて再確認できてよかった。不道徳で人前に出られない業界なんだよ、日本の IT って。
物も分かってないバカが現実を知らずに叩いているみたいな反応をしている人もわりと多くて、それはそうなのかもしれないけど、ともかくこの業界構造を不道徳で汚らわしいものだと考える人が多いという事実は事実として冷静に認識したほうが幸せに近づくと思う。
ほんまそれ
世のなかに、イケてないプログラマというのは確かにいて、これはどうしようもない。彼らを、イケてるプログラマにするのは無理である。自分で何かに気づくのを待つしかない。彼らに対して僕らが出来る唯一の対応は、重要な仕事から遠ざけること。開発チームから外すのが一番だ。互いの幸福でもある。
これは本当にそう
もう今まで100億回くらい言ってきたけど、やっぱりActiveRecordをモデルって呼んでアプリケーション設計の中心におく文化嫌いだわ
MVC2アーキテクチャの時点で過ちの種が仕込まれていたとも言える
優秀な人が多いことで有名な某急成長企業に入ったら思ったより実態がひどかったのでシェア。
・四半期ごとに目標が大きく変わって毎回プロジェクトがストップ。毎Q繰り返していてまともな開発ができない。まるで積み上げても積み上げても完成前に崩される賽の河原。
・プロダクトマネージャーが半人前だらけ。新卒1年目の子達が企画したものを一流エンジニアが開発する体制。当然まともな企画はできないからプロジェクトの途中で問題が次々発覚して最終的には開発中止になる。
・内部で結果を出した人を昇格せずに外部から友達人事で執行役員を連れてくる。が、連れてきた人は大体中小ベンチャーの役員なので急成長中の現在の規模の経験がなく大体結果を残せずに1〜2年で退職。人事に納得がいかない内部の功労者はその頃にはとっくに退職していて人材不足。
・創業者が完全に現場を離れてしまっているので優秀な人材が昇格できない。昔からいる経営層とコネクションある人、目立つ人だけが昇進。
・明らかにマネジメントが崩壊しているのにベンチャーはそういうものだからの一言で済ました結果ミドル〜シニア層が大量離職。それをみた優秀な新卒もこの会社やばいと気づいて大量離職。結果会社全体で大量離職。
みんなネームバリューに騙されないように気をつけてね。
ベンチャーなんてそんなもんじゃろ。
適度に経験を積んだら転職すればよいし、ちゃんとやりたきゃコミットすればよい。役職が欲しければ適当なベンチャー立ち上げに関わればいい。
特に「優秀な人が多いことで有名な某急成長企業に入ったら〜」みたいな新卒というのは、要するに創業者や先達の作り上げた財産に乗っかりたいだけの人なので、自分がどうにかしようという精神が無い。
そのような人間の比重が増えれば会社の組織も腐っていくものである。
つまり、増田っちのような人間達が会社を腐らせていくのであるな。
単に与えられた仕事してるだけのくせに組織がどうのこうのマネジメントがどうのこうのと言ってマウント取っても、自分のスキルが上がるわけではないのだ。
大項目について
ここにはテスト対象を記載します。テストケースの主語になります。品詞でいうと名詞が入ります。注意点というかコツは、ボタンなどの小さなものは書かないことです。大項目にミクロなものを書いてしまうと、中項目と小項目にはさらにミクロなものを書くことになります。そして大項目を洗い出すだけでもかなりの時間を費やすことになります。画面だったり、機能を記載するのがいいと思います。
中項目について
ここにはテスト目的を記載します。少しわかりづらい表現ですが、テストケースの述語になります。品詞でいうと他動詞が入ります。ただし、見やすくするために「～する」の「する」は省略します。例えば、「閲覧する」だったら「閲覧」に、「追加する」だったら「追加」みたいな感じですね。
小項目について
ここにはテスト条件を記載します。テストケースの修飾語になります。修飾語なので、テストの粒度によっては省略可です。パラメータだったり、状態遷移のテストだったら前状態が入ったりします。
※ 大中小項目を見直してみて、それが手順になっていたらアウトです。粒度が細かすぎます。
うむ。
GoやRust、Swiftなど最近の言語は変数の型定義を変数名の後に書くことが多い。
実際違和感はあるものの、どことなく既視感もあって、これはなんだろうか...と考えていたら、「このスタイル、VBやんけ！」と思い至るなど。
VBは↓のように変数の型定義を変数名の後に書く。
Dim i As Intager
Dim s As String
既視感の正体はVBだったというお話。
テストを先に書かずに後からテストを書こうとしても、気づいた時には「とてもじゃないけどすぐにテストを書けない」みたいな設計であることがしばしば。だから先にテストを書いた方が良いのです。
Snapでインストールできるんだ
フリーランスエンジニアを雇う側の人の話を聞いて、治安の悪さがよく分かった🙃契約結んでお金だけもらって働かずにクビになるまで待つ、というタイプの人々がいるらしい…
bioに「フリーランスエンジニア！月収100万！」とか書いてあって、謎の意識高いツイをしているだけの人々の正体が分かった気が
契約結んでお金だけもらって働かずにクビになるまで待つ→クビになったら他の会社でまた同じことをする（経歴も詐称したりする）という感じらしい
言うて、一ヶ月進捗無かったら契約切るだろ...
一ヶ月単位でプロジェクトを転々としてるエンジニアはやべーやつというサインなので、普通に書類選考時点で遠慮されるもんだと思うけども。
N-gramかつC言語ライブラリ形式の全文検索エンジンを探していてその存在を知ったのだが、最早どこにもソースコードは公開されていない模様。ライセンスはGPLなのだが。
開発者にRubyのまつもと氏の名前があるのだけど、その後どうなったんですかね...
IPAからの委託開発らしいので、契約終了＆メンテナンス放棄で終わってしまった可能性が高そう。
2004年にはGitHubなんて無かったし、アーカイブもされていないのだろう。
まぁしゃーない。
例えば、次のような脈絡のないデータリストがあったとする。
["1", "2", "3", "Apple", "Orange", "100", "Fish"]
この中から文字列の項目のみ抽出したいと考えた時どうするべきか。
まず、普通にfor文でループさせていく方法があるが、ここではスルーする。
もうひとつのパターンとして、filter関数を使うこともできる。
リストからの抽出であればfilter関数を使う方がシンプルに書ける（らしい）。
具体的には以下のようになる。
import re
def serch_keyword_re(keyword_re, values):
r = re.compile(keyword_re)
return filter(lambda val:r.match(val), values)
if __name__ == '__main__':
values = ["1", "2", "3", "Apple", "Orange", "100", "Fish"]
result = serch_keyword_re("[A-Za-z]", values)
print(list(result)) # ['Apple', 'Orange', 'Fish']
if文が（見掛け上）消えたのですっきりしたように見える。
ついでに関数化することで何となく再利用できるようにしてみた。
とはいえ、この程度ならリスト内包表記で十分なのでは？？ 感はある。
「最適化」という言葉は耳ざわりがいいので、つい使ってしまいます。あなたの所属する会社の事業紹介にも「ナントカ最適化」が載っているかもしれません。詳細に話しても理解してもらえないお客さんには「ナントカ最適化」という言葉で納得してもらうしかないでしょう。「最適化」という言葉は非常に耳ざわりが良いので、その言葉を使っているだけで何か仕事をした気になってしまいます。
しかし単なる「最適化」では、「何をどうするのか？」という意味が欠落してしまっています。そのため、そこで使われる「最適化」には「いい感じにする」「頑張ります」以上の意味合いはない、思考停止ワードになってしまっています。
もしあなたがエンジニアやサイエンティストではないなら、「最適化」という言葉を使うことをやめ、「最大化」や「最小化」という言葉に置き換えましょう。すると、隠れた前提条件や、目的変数を見つけ出し、その前提条件や目的変数をどのようにしたいのか、ということを考えることができるようになります。
「最大化」「最小化」という言葉に置き換えるだけで、数値計測可能な目的変数は何で、それを実現するためにどのような前提条件が存在するのかを考えることができ、問題がクリアになっていきます。
Amazonのライティングのように数字（実験結果）で示すことはなかなか難しいので、まずは「最適化」を「最大化」「最小化」に置き換えていきましょう。そうすることで、前提条件や制約条件が何で、どのようなことをすると、目的変数が得られるのか、というところに注意を払えるようになります。
Swayはタイル状のWaylandコンポジターであり、X11用のi3ウィンドウマネージャをドロップインで置き換えるものです。既存の i3 設定で動作し、i3 のほとんどの機能に加え、いくつかの追加機能をサポートしています。
とのこと。
基本的にi3の情報を検索すればOKという感じみたいだ。
基本的にブラウザとエディタ以外はあまり使わないのでこれで必要十分な感じはある。
ソースコードではなくドキュメントがほしいのは、
全体の俯瞰や全体の関係性
一覧性
プログラミング言語を読まない人との認識合わせ
などが理由。
ビジネスで関心のある値を独自の型で定義して、全体の構造や一覧をソースコードからJIGで可視化すると、ほとんどのドキュメントは代替できそう。
ふーむ（判断保留）
結局具体的なことが何も書いてなくね？ 動画見ろってことか。
上記以外にも非正規化テーブルで構築した方がよいケースとしては、外部システム（API）のレスポンスを保存する時である。
例えば、決済システムの決済結果レスポンスやマッシュアップ的なシステムで別サービスのAPIからデータを取得して表示するような場合が該当する。
外部システムのデータフォーマットは利用者側では制御できないものであり、場合によっては事前通達も無しにフォーマットが変更されることも有り得る。
この為、データフォーマットに合わせて正規化されたテーブルを作成するのは手間の割に得られるメリットはあまり無い。
更に言えば、そのようなテーブルは証跡としての役割が主であるため、とりあえずデータが入っていれば十分とされるケースも多い。
であれば、レスポンスをそのまま保存した方が合理的である。
したがって、外部システム（API）のレスポンスデータはいちいち正規化したテーブルを作成したりせず、シリアライズしてひとつのカラムに放り込む設計にした方がよい。
アジャイル手法はプログラミングをソフトウェア開発の中心的役割に押し上げた、とよく言われる——ソフトウェア エンジニアリング コミュニティがやってるようなことよりもずっと優秀だよなあ。 プログラミングが中心的役割となったのは、コードをソフトウェア システムにおける「（最）重要なドキュメント」と位置付けたことが理由なんだと思う。
おっと、よく誤解されるので先に反論しておこう。 先ほどの「コードは重要なドキュメントだ」という原則だけど、 「コードが”唯一の”ドキュメントだ」とは言ってない。 「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。 コードを補完するには、他にもドキュメントが必要なんだ。
コードがドキュメントなら、プログラマがコードをクリアで読みやすくするよう努力することが重要となる。 「コードがドキュメントだ」ということは、「特定のコードが良いドキュメントだ」ということじゃない。 どんなドキュメントでもそうだけど、コードだってクリアにもなれば、ごちゃごちゃになることもある。 コードだから他のドキュメントよりもクリアになる、ということもない。 （他のドキュメントも絶望的なくらい不明瞭になることがある——以前、どうしようもないUML図を見たことがあったなあ。 (「死んだ馬に鞭打つ」じゃなくて)「人気のある馬に鞭打つ」って感じだけど。）
これから、いろんな点で反対する人に出会うかもしれない。 だけど、これは覚えておいて欲しい。 「コードはチームの所有物である」（細切れのコードは個人の所有物であってもだ）。 プロのプログラマというのは、チームのために自分のスタイルを曲げる覚悟があるんだ。 たとえ三項演算子が好きでも、チームが分かりにくいと感じたなら、使わない。 自分スタイルのプログラミングは、個人プロジェクトでやればいい。 チームでやるときは、チームの要望に従わなくちゃ。
プロダクトマネージャーが用意するリスト
- 目的の概要（なぜそれをやる？）※もっともだいじ。これが無いとかなりキツイ。
- 誰のための企画？（基本はエンドユーザーになる。）
- その人のどういう課題を解決したい？
- その課題はどうやって導いた？（根拠となる情報やデータなど）
- 企画内容の概要（なにを提供する？）
- どういったソリューション（機能など）を検討している？（実装前の現段階ではただの仮説。細かい仕様はむしろ無いほうがいいが、UI の手書きラフスケッチくらいはあるとやりたいことがイメージしやすくなる）
- どのへんの既存機能に手が入りそう？とかもあるとよさげ
- 現状なぜそのソリューション（仮説）が妥当だと考えてる？（根拠となるデータや情報、市場分析や競合分析結果など）
- 戦略との整合性（なぜそれをやる？の追加情報）
- プロダクト戦略や、事業戦略との関連性はなにか？（ダイレクトに効いてくる？周辺領域？）
- ソリューションが実現された場合の想定インパクトは？（どんなメトリクスにどれくらい寄与する？ざっくり。取らぬ狸の皮算用だが、投資価値があるかどうかのざっくり判断などにつかう）
- スコープやスケジュール（いつ、どれだけ提供する？）
- ソリューションに対するスコープの選択肢は？（特にミニマムスコープ。「これさえあれば課題を解決できる！」という削ぎ落とされたソリューションの範囲は？）
- スケジュール特性は？（早さよりも、期日を設定してそれを守ることが重要？もしくは その逆？）
こういったものがあると、できるようになる話
- 技術的実現性やリスク
- そもそも実現可能かどうか
- 懸念やリスクについて
- 技術的難易度が高そうなところ（高コストになりそうなところ）
- 考慮漏れしそうな部分、既存仕様と競合しそうな部分（慎重に考慮したほうがいいところ）
- 代替手段やスコープの案
- もっと簡単にその課題を解決する方法
- こういったミニマムスコープもありそう、みたいなもの
- ざっくりとした見積もり
- やるべきかの判断のための、ざっくり開発規模感（Not 納期の約束。この時点ではとてもじゃないけどできません）
正直下らないな以外の感想が無かった
今までSEをしてて一番くだらないなぁとおもった作業は設計書の項番に①とか②を使ってて、51が登場したときにマル付きの数字ないじゃんってなって、全設計書を修正したことです。
本当にくだらなくて草
わたしはGitもオブジェクト指向もWebフレームワークも自動テストもCIも、とにかく最近のモダンな開発手法やツールをほとんど知らないままに6年生きてきた。そういうことを知っている人がいない環境で6年間生きてきた。
9年プログラミング歴があったら、だいたいほかの9年仕事している人と同じくらい、そうでなくてもせめて5〜6年以上プログラミングしている人並みのスキルを保持していることを暗に期待され、その後幻滅されることが多いように思う。
いや、自分ですら、どこかで自分に対して「経験年数これぐらいあるからこれぐらいすごいはずだ」みたいな勘違いをしてしまったことが時々あったような気がする。外から目に見えるアウトプットはこれからもっとしていくべきだし、その成果物のみを自分の実力だと思ったほうが実状に近い。
自分のいまのスキルを客観的に見て、成長の早い他者の経験年数と自分を比べずに日々勉強と経験を積み重ねていく、そのことのみに集中しよう。社会がエンジニアの経験年数に重きを置かないにようなったほうが私にとっては不幸が少ないと思っているが、なかなかすぐには変わらない部分もありそうだ。せめて自分としては、経験年数にとらわれず自分なりに前に進んでいく、そういう心構えで生きていくしかないのだ。
とはいえ、市場価値というものは残酷だからなぁ
そうだったのか。
Poetryにもプラグインで実現する構想はあるみたいだけど、まだリリースされていないみたいだ。
↓を使ってみるのも面白いかもしれない。