「コンポーネント」を含む日記 RSS

はてなキーワード: コンポーネントとは

2021-10-11

或るリサイクルショップで騙されそうになった話

リサイクルショップの店内をうろついていたら、既にディスコン品となった自転車部品が売られていた。

外箱の機種のチェック欄の所には正式な機種(グレード)も記載されていた。

箱入りで未使用品、しか格安だった。

Webサイトでは新品(未使用品)が売られている事も有るが、価格が下げられていることは無い。

最初は購入を躊躇った。

古い機種の部品を寄せ集めて一式揃えるのか、全く新しい機種で一式を揃えるべきか。

一週間悩んだ挙句、古い部品を購入することとし同ショップを再訪した。

レジで念のためラップを外してもらい、箱の中身が未使用かどうかを確認した。

 

家に帰り、暫く手を付けていなかった自転車を、汗だくになりながら分解と掃除した。

さて新しい部品の取り付け、箱から取り出し取り付けようとしてぎょっとした。

箱に書かれている機種と、部品のものに書かれている機種名が違っている。

下位グレードの部品だ。使用する3つの部品全てを調べてみると、全て同じ下位グレードの物だった。

騙された!と思った次の瞬間、もしかしてリサイクルショップも騙されたのか?という思いが沸き上がってきた。

レジで箱を開けた時、部品を細部に渡って確認するべきだった。

箱に書かれた機種名だけを信頼してしまった事を悔いた。

 

取り急ぎリサイクルショップ電話し、箱と中身が違う事を説明し返品可能か聞いてみた。

電話対応してくれた男性謝罪言葉と、申し訳ないが返金処置に来てくれという事を言ってくれた。

ここで疑問なのが誰が悪かったのかということだ。

リサイクルショップに持ち込んだ人をAとする)

  1.Aが、騙すつもりで下位グレードの部品を入れて、事情に詳しくない店員はそのまま受け入れた。

  2.Aは箱と中身が違う事を説明し、店員理解した上で受け入れたが、箱と中身が違う事を表示しなかった。

  3.細部まで確認せずに購入した俺が悪い。

1ではAが悪いが、2では店員が悪いのではないかと思うのだが、犯人捜しをする意味も無いだろう。

結局自転車は分解掃除されたままの状態となっている。分解する前はまだなんとか走れたのだが。

ディスコン品の未使用部品を寄せ集めても、中途半端な出費となるが、

新しいコンポーネント一式買い揃えるにはかなりの出費となる。

さてどうしたものか、また悩むこととなった。

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、REST API のような単一の振る舞い(エンドポイント)とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション通信の潮流と、計算資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。

まり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。

なので、以下のコメントちょっと論点がずれてると思いました。

はあ?「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わりますオブジェクト指向とはほぼ無関係です。

https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin

なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない

https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang

しかに、アプリケーション単位アプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います

ソフトウェア記述をまとめるという視点では主にステートレス関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理やすくするという視点ではオブジェクトというのはライフサイクルリソース管理視点が足りず小さすぎる、ということで、オブジェクト指向粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います

個人的にわからなかったのは以下の部分です。

オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない?」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。

当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの?」って思ってしまますオブジェクト指向定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェア組織化すること」なのであれば)。

おわりに

Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

2021-08-28

革新的で軽量なブラウザー(自称)、Floorpブラウザこき下ろす

Floorp ウェブブラウザと名乗るブラウザ最近出てきて、開発が終了したKinzaパッチが公開されたら取り入れると宣言してKinzaの後釜を狙ってるらしい。中の人高校生らしく、使っていくうちにチャラさ、痛々しさが目立ってきたのでこき下ろしていきたい。

このブラウザが気になってしょうがない人はTwitterアカウントに行けばダウンロードリンクがあるのでダウンロードして確かめればよい。

※以下の話は、断りのない限り8/28に公開された公開ベータ版(v1.1.3)のことである

使用許諾契約書に突っ込みどころが多すぎる (v1.1.3)

インストーラーを実行するとまず使用許諾契約書が出てくる。

*Floorpブラウザ利用規約

---------------------------------------------------------------------------------------------------------------------------------------------

Floorp デベロッパープレビュー利用規約

1.Floorpをお選びいただきありがとうございます。高速で軽量なブラウジングをお楽しみください。

2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、ChromiumライセンスBSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。

3.Dev Previewエディションの場合TwitterなどのSNSスクリーンショットなどをアップグレードしないでください。

4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。

5.Ablazeの利用規約に沿って本ソフトをご利用ください。

6.以下に表示されている利用したオープンソースソフトウェア感謝しましょう。Floorpはこれがなければ実現しませんでした。

7.開発者はあまりすごいことをしていないことに気づきましょう

8.ソースこちhttps://github.com/Ablaze-MIRAI/Floorp-Browser

---------------------------------------------------------------------------------------------------------------------------------------------

利用したオープンソースソフトウェア

[※以下略]

さて、どこから突っ込もうか。

Floorp デベロッパープレビュー利用規約
いやこれ、公開ベータ版でしょ?
Floorpをお選びいただきありがとうございます。高速で軽量なブラウジングをお楽しみください。
これ、規約内に組み入れる必要あります
スクリーンショットなどをアップグレードしないでください
アップグレードwwwwwどうやったらアップグレードできますかね?めっちゃ草生えたわ。
感想やご不明な点がございましたら、お聞かせください。これは義務です。
あったら教えてなのに義務と言い切る。どっちなんだよ。
Ablazeの利用規約に沿って本ソフトをご利用ください。
それなら「Ablazeの利用規約」とやらをここに載せろよ。超不親切。
開発者はあまりすごいことをしていないことに気づきましょう
これ、規約内に組み入れる必要あります

8/29公開版(v1.2.4)の使用許諾契約書は遊びすぎ

*Floorpブラウザ利用規約

---------------------------------------------------------------------------------------------------------------------------------------------

あああああああああああああああああああああああああああああああ開発つかれた

1.Floorpをお選びいただきありがとうございます。高速で軽量なブラウジングをお楽しみください。

2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、ChromiumライセンスBSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。

3.Dev Previewエディションの場合TwitterなどのSNSスクリーンショットなどをアップグレードしないでください。

4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。

5.Ablazeの利用規約に沿って本ソフトをご利用ください。

6.以下に表示されている利用したオープンソースソフトウェア感謝しましょう。Floorpはこれがなければ実現しませんでした。

7.開発者はあまりすごいことをしていないことに気づきましょう。後眠いんだけどどうしよう?癒してください!彼女ください()

8.Floorpは有志によって無料提供されています寄付は受け付けますのでダイレクトメッセージ https://Twitter.com/Floorp_Browser へお越しください

9.ソースこちhttps://github.com/Ablaze-MIRAI/Floorp-Browser

[※以下略]

利用規約をなんだと思っているんだ。「利用規約は楽しく、ユーモアにありふれさせたい」とか「Floorpの利用規約最後に・彼女になることに同意しますか?って書けば同意させられんじゃん」とかつぶやいてる時点でなめてるしふざけてる。

公開されているソースコードタイトルが痛い

Ablaze-MIRAI/Floorp-Browser: Chromiumで一番軽量なブラウザの大部分のソースコードです。

というタイトルなのに、実際に公開されているのはブラウザコンポーネントに比べてかなり少ない。これのどこが「大部分」なの?

あと何の根拠もなく「Chromiumで一番軽量」って言い切ってるだけで相当痛い。一番軽量かどうかは知らんが、メモリ使用量が少ない=軽量と思い込んでる節がある。ほか、

Chromium本体BSDにのっとって公開なし

という文は誤解を生むから今すぐ止めろ。これだとBSDライセンス違反するぜ!と宣言してるような解釈もできるから利用規約OSS感謝しましょうとか言っておいてこの扱いひどくないか

ブログ記事も痛い

このブラウザ自己紹介記事(https://blog.ablaze.one/573/2021-08-16/)が先週公開されていたが、ここに書かれてる内容も相当痛々しい。

メモリ使用量が少ないのは見せかけ

ブラウザインストールするとメモリカスタマイザーなるものが同時にインストールされる。これが動作することでFloorpブラウザメモリ使用量が劇的に減ってるから軽い、ということらしい。

しかし、ブラウザを起動したまま放置してみてから、実際のWindowsタスクマネージャーの様子をよく見てほしい。メモリ使用量が数MBとありえないぐらいまで減っているのがわかるだろう。Windowsタスクマネージャー上ではメモリ使用量が減っているように見えるが、ブラウザタスクマネージャーで表示されるメモリ使用量はそれほど減っていない。では何が起こっているのか?

メモリカスタマイザーの正体はFireminである名前の通り元々はFirefox用で、仮想メモリにページアウトさせて物理メモリ使用量を減らすものらしい(実際の動作は細かく見てないのでよくは知らない)。Fireminの名称変更、起動時にFloorpを自動的対象にするといった改造を施している。FireminによってWindows10の途中の大型アップデートから搭載されたメモリ圧縮がより積極的にかかるようになり、物理メモリ使用量も減らせるメリットはあるようだ。YouTubeトップページを開いてしばらく待った時、メモリカスタマイザーの使用時と未使用時で約0.1GBの差はあるのは確認できた。ただし、メモリ圧縮の代償はパフォーマンスの低下。特にページアウトによりディスクI/Oが増える。ディスクI/Oが足を引っ張って重くなる場合があるので、必ずしも軽いとは言えない。

結局の所、Chromiumを改造するなどの根本的な解決策を取っているのかは疑問である(もししているならTwitterなりに書いているだろう。技術アピールができるし)。Floorpブラウザの作者はWindowsタスクマネージャーに出てくる見せかけの数値だけを見て「えっ、Floorp軽っ、、、、、」とか言ってるのだから、実に恥ずかしい。いつ気がつくか見物である

メモリ節約(?)のせいでパフォーマンスが落ちる

500ms単位メモリ節約機能動作するせいで、Speedometer 2.0ベンチマーク結果がさえない。未使用時と比べて7%ぐらいスコアが落ちてる。Edgeよりもスコアが良くない。メモリ使用量のことばかり気を取られて、速度のことには関心がないのかもしれない。

インストールされる拡張機能が他のChromium派生ブラウザに影響を与える

Chrome Web Store外から拡張機能(Deepl翻訳と同期機能)をインストールさせるためにレジストリ使用した結果、他のChromium派生ブラウザ(SRWare Ironで確認済)でも拡張機能インストールされたという通知が表示されるようになってしまう。

その他

インストール先がCドライブ直下

Cドライブ直下フォルダー作ってそこに入れるとか、いつの時代ソフトだよ。Program Filesに入れてやれよ。

FloorpLuncher.exe

スペルミスウケるwwwこれじゃ昼飯食う奴じゃんwww

Wikipediaの該当記事が早々に削除されそうになる事態

https://ja.wikipedia.org/wiki/Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/Floorp

https://twitter.com/surapunoyousei/status/1431961462734352385

作者から依頼されて書かれた記事客観的証明なんてどうやってするんだろうね。

本番はこれから

まあKinzaパッチが出てからが本番っぽいし、それまではこれぐらいにしておこうか。

メモ

Uniant Browser → Floorp Browser? UniantとAblazeの関係がよくわからん個人で開発してるのか寄り集まって開発してるのかもよくわからん

2021-07-22

過去1時間に12460のシステム警告

イベントビューア曰く1秒間に20くらいの警告イベント

修正されたハードウェア エラーが発生しました。

コンポーネント: PCI Express Root Port

エラー ソース: Advanced Error Reporting (PCI Express)

プライマリ バス:デバイス:機能: 0x0:0x1C:0x4

セカンダリ バス:デバイス:機能: 0x0:0x0:0x0

プライマリ デバイス名:PCI\VEN_8086&DEV_9D14&SUBSYS_07671028&REV_F1

うん、ノートPCマザボの近くで物理的になんかアレな雰囲気パームレスト付近を強く押したり本体ゴンと衝撃強めに置くといろいろ起こる)

これ記録行為無効にできないかなあ

これ起きるとシステム動作10秒くらい止まるんだよね

2021-07-06

プログラム好きだけど、IT業界辞めることにした

プログラミングが嫌いならIT向いてないよ~、っていう論調転職勧めてくるブログばっかでウンザリしたので、プログラミング好きだけどIT辞める話する。

当方エンジニアプログラミング歴5年くらいのペーペー経験はチームリーダーちょっとあるくらい。転職したくせにSIer

辞める理由プログラミングする時間がないのと、新しい技術触れないから。

ここで、鋭くツッコミが入るだろうよ。おいおい、天下のITでそんなことあるはずないだろ?って。

ところがだよ、この業界の連中全然新しいの手出さねーんだよ。

未だにコンテナもCICDも知らなければ、クラウドとか危ないだろ?オンプレが一番とか言い出す連中ばっかだよ。

一時期、IaCだの、コンテナオーケストレーションだので夢中で遊んでて、業務にも取り入れよう!きっと同志がいるはず!と思い立った俺が馬鹿だったよ。

こいつらに利点説明しようがねーよ。「俺らプログラマからインフラ分かんないんだよね~」とかほざきやがるよ。コンテナなんかもう開発で使ってる奴アホほどいるだろ。

でも、まだ夢を見てたよ。自分アプリ作ってみたり、色んな言語にも触れてみてさ。

bluetoothだの、ラズパイだの、クラウドだの、ブラウザARだの、WebAssemblyだの色々触ってみたよ。全部面白かったよ。

そんで、気づいちゃったよ。俺、これできてどうすんだ??って。こんなの仕事になんねーだろ??って。

で、嫌気が刺して転職活動したよ。俺も夢見たよ。モダン環境ソースコードはGitLabとかCodeCommitとかで管理されてて、pushされたら、JenkinsおじさんとかCodeBuild君がビルドして、単体テスト環境コンテナイメージがGitLabCIとかで起動して、テストパスしたらmasterにマージされてバージョンタグも割り振られていつでもどこでも最新の実行環境が用意されてんだろって。

ドキュメントなんかはこんだ、社内のWikiでもって管理されてて、コーヒーでも啜りながら見れるんだろって。

UMLなんて、mermaid.jsだのnode-plantumlだの、draw.ioだので書いて、Officeなんて出番ない位モダンで人の手の入る余地なんてなくってさ。

フロントエンドなんてコンポーネント単位でStorybookなんかで管理しちゃってさ。

テストなんかE2Eだよ。人なんかいなくてもよくってさ。

でもってサーバークラウドだよ。ソースコード規約でしっかり管理されてて内部設計書なんて不要なくらい綺麗でピシっとしちゃってさ。

同僚なんて最高だよ。いつだってモリモリ新しいの追い続けてるイケイケのイケメンよ。

そんな環境を夢見ちゃったよ。

うん。ないよな。あるわけねーよ。ってかレベル高すぎて入れねーよそんな会社

でもさ、少しでもちょっとでもあってもいいじゃん。なのに、求人票に書いてあるのはいものつまんない仕事のことだよ。

要件定義がどーとか、詳細設計がなんだとか、大手金融顧客にしてますとか、言語JavaC#PHPSQLだよ。

しょうがいか転職したよ。その時の会社よりマシかなと思ったから。でもやっぱつまんね。使ってる技術は古いし、いつまでもExcelだし。

結局、ITなんて道具でしかないんだよな。金持ちお客様欲望叶えるためのツールよ。

世間的には必要とされてるアプリってのは、何か優れてるとか、プログラムがすごい、とかじゃない。

たまたま間に合わせで作ったアプリが、たまたま使い続けられてしまって、信頼と実績を築き上げてしまっただけってこと。

ただサービス企画広報が優れていれば、後ろで動いている技術なんてどうでもいいってことを理解してしまった。

それが、たまらなく悲しい。

エンジニア志望の未経験はよく見とけ。ブログ界隈でもてはやされてるWEBアプリ実態なんてこんなもんだよ。

で、IT業界をやめる。なんでかって言うと、仕事としてやるプログラミングがたまらなくつまらなくて苦行でしかいから。

いやいやと、職業プログラマーってプログラミング好きなやつには天職じゃないんかって?

こんな窮屈な環境プログラミング好きなんか言えないし、プログラミング趣味でやるだけなら、趣味時間取れる仕事の方がいいし、じゃあプログラマなんて選ばないよねーってだけよ。

っていうか多分、新しいもの面白そうなものが好きなだけで、プログラミング自体はそんな好きでもないんだろうな。

というか、プログラミングで金稼ぎたいとか、社会に役立ちたいとかって欲求がないんだよね。

多分、プログラマ以前に社会人として終わってんだろうな。責任感とかねーもん。今のプロジェクト燃えちゃって会社に損害行っても、それで懲戒免職かになってもいいと思ってるもん。

人間としても俺終わってるな。でも今となってはどうでもいいわ。

ということで辞める。次の仕事は決めてない。でもIT以外の業界ってすべからくつまんなそうなんだよな。うーむ。ニートするか。

2021-06-17

CTOだけど、一ヶ月Web就職レビューしてみた。

https://anond.hatelabo.jp/20210617075257

0. 温度感

基本的現在では、バックエンドフロントエンド運用保守全てができないエンジニア価値は無い。

経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。

典型的はてなー意識の高さ。

上がってるような基本(元増田に上がってるやつの倍ぐらい)が全部立ち上げからできて

2〜3個プロジェクト経験したらテックリード素養が既に身についてそう。

まり、ただのエンジニアにはそこまで要求されない。

プロジェクト的にもどっちかが弱いと

Rails/DjangojQuery+Bootstrapみたいな構成

Amplify/FirebaseにVue/Reactみたいな構成全然あるので

フロントバックエンドも一旦はどっちかでいい。

面接はなんとか抜けてもらうとして、

チーム開発での最低限の目標としては、

成果物から指導学習コストレビューコスト技術負債マネジメントコストを引いた分が正になっていれば

ひとまず「チームに居ていい人」と見なされそう。

チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、

一旦は、正の生産性を目指してほしい。

以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、

一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。

1. 言語: PythonJavascript

これだけで一ヶ月経つ気がするが正気か。

似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。

どっちかしかやらないならJavascriptおすすめ。後ででてくる、Flaskは適当Expressかに置き換える

現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。

どちらも、Python2とES2015以前の記法というレガシーネット上に転がってるので参考にしないように注意。

パッケージ管理単体テストタスクランナー

この辺は6のフロントフレームワークと同時にやる。

コードは断片的なサンプルではなく

一貫性があって

・正しい書き方がされた

お手本プロジェクトをなにか(github書籍など)で手に入れて読むべき。

おそらくフレームワークに乗っかっているので並行して進めることになる。

6. フロントエンドフレームワーク: Vue.js

話の流れで先にこっち

現在コーディングのグッドプラクティスデザインパターンフレームワークの形をしている。

なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。

とはいえ最低限としては使い方が分かるところまで。

TypescriptVue.jsも書き方をどこまで取り入れるかが使用者裁量に任されてるし、

開発でVueとReactのどっちを使うかはチーム次第なので、

一旦React+Typescriptガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。

2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。

パッケージとかテストタスクデプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。

2, 4. ツール: gitDocker

バージョン管理コンテナ思想が優れているのは自明なので、これらはツールと見ていい。

そして、後からプロジェクトに入った人がプロジェクト流儀に沿って使う分には難しいことはなさそう。

採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、

そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。

構築できる、ではなく、触れる程度で良さそう。

gitプロジェクト流儀によると書いたが、git-flowイメージ図を理解して運用できるのがよい。

https://qiita.com/KosukeSone/items/514dd24828b485c69a05

3. OS: Linux

これは「パソコンの使い方わかってますか」ぐらいの温度感

ファイルパーミッションユーザープロセスのような基本概念理解する

一冊読めば済むだろうし、概念系はさらっておいてほしい。

grepやfindやxargsなどのコマンドを組み合わせて簡単な処理を自動化する

こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。

sedとか正規表現も。

あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。

IPアドレスを調べたり、SSHリモートマシンログインする

地味にSSHログインした先の環境だと、vimが主要なテキストエディタになるので

vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。

ファイル開いて入力モードに切り替えて書き込んで保存して終了

チュートリアルする。拡張とかはいらない。

細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。

5. サーバーフレームワーク: Flask

フレームワークを覚えること自体重要なのではなく、Web開発の基本を習得することが重要

これが意図なら

HTTPルーティングデータベースSQL認証セッション管理などは当然すべて覚える。

この辺の機能を持った小規模Webアプリを作ってHerokuデプロイすれば一旦完成とみなしてよさそう。

コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい?

慣れると1日あればいけると思う。

フレームワークもなんでもいい。

軽量である必要もなくて、

Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。

余力があれば複数個触ってみたり、人から勧められたらそっちでも。

最近サーバーレス&NoSQL流行ってるのでFirebaseとかもやればいいと思う。

7. アルゴリズム

コメントリーが荒れててウケる

実務プログラミングで最低限必要アルゴリズム力は

「書いてるコード計算量オーダーを把握していること」

に尽きる。

計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて

O(n^2)やO(n^3)のロジックを書いてしまって

データ量が万〜十万の本番データで遅延するとか

それらに対して分散や非同期処理で解消しようとするとか、

ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為

アルゴリズム不要勢は平気でやるぐらい、両者は溝が深い。

計算量を意識するだけなら、AtCoderABCのC〜D問題辺りが解ければ十分。

8. セキュリティ

有名な脆弱性攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている

(XSS対策自動エスケープなど)

のでアドリブをせずに正しい書き方でやれば良い。

開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、

ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。

最後

開発の勉強のやり方としては、

・正しいコード見本を手に入れること

公式リファレンスを読むこと

エラーメッセージを読むこと(そしてググること)

この辺りの習慣があればやってけんのかな、

その他、チーム開発って面では

アジャイルサムライプロジェクト管理)とか

TeamGeek(人間性)とかインプットしておくと共通言語が増えて嬉しい。

この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、

そしたらやってけるんちゃうーって感じ。

2021-04-23

Linuxをパーツの一つに貶めようとするMSの策がエグい

MSが恐れていたLinuxは今はもう無く、サーバ市場MS利益をもたらす家畜になった。

そして今となってはデスクトップOSとしての可能性がMSによって摘み取られようとしている。

WSLでGUIアプリが動くようになることで、GPUメーカーは最新チップドライバLinux提供する意義を少し失う。

ゲーム用のGPUに限ればかなりの意義が失われる。

LinuxOS自体デスクトップOSとしてベアメタルに載せる意味が薄くなっていく。

Linuxwindows浸食しているのではなく、Linuxwindowsの単なるコンポーネントの一つになりつつある。

UEFIの為にプロプライエタリという毒を喰らわざるを得ない状況もWSL向けディストロなら不用だ。

MSに飼われ続ける限り、最新GPUの性能を活かしたプログラムを動かせるし、そのほかのデバイスもどんどん使えるようになるだろう。

windowsコンポーネントの一つになった方がデスクトップOSとしてLinux価値が上がってしまうと言うのはなんとも皮肉な話だな。

2021-04-07

vueコンポーネントが動かないな…

と思ったらコンポーネントelタグの外だった…

そりゃあ動かんわな…

2021-03-23

Tailwind難しすぎワロタ

普通CSSフレームワークコンポーネントを組み立てればまあそれなりな物ができるけど、Tailwindはコンポーネント作るところから自分でやらないといけない。

そんなんできるわけないじゃん。

デザイン強者が「すげー簡単!好みに合ったコンポーネント簡単に作れる!」ってイキってるだけだよあれ。

びっくりだよ。

難しいよ。

2021-03-02

[]2021年2月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

288あとで/2715users 大学の恩師に教わった、「なにがわからいか、わからない」とき質問のしかた。 | Books&Apps

281あとで/1814users 最初の一歩を踏み出すという汎用的な技術 - 本しゃぶり

250あとで/1465users 線形代数アニメーション幾何学的に簡単理解できる36記事まとめ | HEADBOOST

236あとで/1717users ASCII.jp天才プログラマーオードリーさんがたった200行で効果的なアプリを作れる秘訣

221あとで/1568users 「140秒とは思えない満足感」「なぜこれだけの傑作が埋もれているのか」 崩壊した日本を旅する“最後動画配信者”のショートフィルム話題(1/2 ページ) - ねとらぼ

215あとで/1805users メルカリ検索に「売り切れ品」を置く理由、初期のLINEが友だち追加を「電話番号マッチング」に絞った理由など、アプリマーケティング施策まとめ30|アプリマーケティング研究所

189あとで/1454users 暇を潰せそうなサイトを沢山見つけたので貼りまくる:哲学ニュースnwk

174あとで/1269users メルカリ、「無意識アンコンシャス)バイアス ワークショップ」の社内研修資料無償公開 | 株式会社メルカリ

161あとで/1028users 文系パパエンジニア放送大学等でコンピュータサイエンス数学を学んで理系学士を取りに行く話 - とあるCS学徒のブログ

154あとで/906users Google TypeScript Style Guide

151あとで/1192users ゲームを作ったらハリウッドから映画化オファーが来た話 - Hirayaブログ

141あとで/1330users オーケーとその他スーパーたち - 14店舗フィールドワークと500人のアンケートでわかったシンプル結論太田正伸|note

139あとで/819users 『ゼロからOS自作入門』に込めた思い - uchan note

134あとで/712users 元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL

133あとで/1430users 游ゴシック話題解説 | anond.hatelabo.jp

132あとで/1127users 36歳で印刷会社社長になった僕が、減り続ける売上をなんとか立て直した話|工藤太一印刷会社二代目/glassy株式会社代表取締役note

128あとで/799users Linuxの基礎用語を完全理解するためにエンジニア作成した「10ミニプロジェクト」とは? - GIGAZINE

127あとで/795users よく見かけるレイアウトUIコンポーネント、それだけを実装するHTMLCSSのシンプルコードのまとめ | コリス

126あとで/1200users 「こんなん履いててプログラミングできるわけない」天才プログラマー登大遊氏が情熱大陸に登場、名言を連発しザワつくTL - Togetter

124あとで/543users 仕組みから理解する Git 入門 ~ ひとり開発でも便利 ~ - Speaker Deck

123あとで/612users Webエンジニア勉強できるGit Repository 10選 - Qiita

118あとで/848users シェルスクリプトを書くときにいつもやるやつを調べた - Please Sleep

117あとで/990users 「SEOに強いHTMLの書き方」についての個人的見解 | TAK | Zenn

117あとで/645users 英語力と技術力向上のための海外Tech系Youtuber10選 +n - Qiita

117あとで/1337users EXPERIENCE JAPAN PICTOGRAMS | 日本デザインセンター

117あとで/882users 管理職のための役職引退マニュアル | DevelopersIO

116あとで/1931users 森氏辞任に考える 日本社会に残る無意味風習: 日本経済新聞

115あとで/1126users いとうまい子アイドルだった私が遺伝子研究者になるなんて」|芸能婦人公論.jp

114あとで/617users 「挑戦させすぎ?」マネジメント勉強会で分かった組織課題とその解決策 - ZOZO Technologies TECH BLOG

114あとで/646users GitHubのawesomeリストが本当にawesomeものばかりだから一度見てほしい - Qiita

生活感のあるエントリが無かった

2021-02-28

Reactむずいいいいいいい

コンポーネントに分割しすぎ

2021-02-20

anond:20210220225656

予算が限られているなら、

急いで買い揃える必要はないと思う。

徐々に買い足していけばいいと思う。

慌てないことが割と大事かな。

 

乗り始めはお尻が痛くなる。

そのことへの対策のため、サドルやパッド入りの下着が欲しくなる。

でも、しばらくするとお尻が慣れてくるから、そういったもの必要がない場合もある。

から、しばらく様子を見ることが必要になる。

慌てないことが大事

 

自転車にハマった場合クロスバイク部品を交換したくなる。

タイヤホイールコンポーネントとか。

でも部品を交換したところで結局クロスバイクだと満足できなくなるからロードが欲しくなる。

だったらクロスバイク予算を使わずロード貯金をするべきだ。

慌てないことが大事

 

そんな感じかな。

まあ他人への最適なアドバイスなんて出来ないから話半分に聞き流してもらえたら。

あと自転車から離れて長いか最近事情はわかってないということと。

2021-02-14

anond:20210214221545

え?ファンクラブアプリUIは、新しいAndroidでも互換性はあるか?

いやそもそも、ご指定コンポーネントAndroidにはどのバージョンにもないです。

すべてフルスクラッチコンポーネントごと書き起こしているか

問題ないです。

2021-02-07

anond:20210207104731

規模がでかくなりすぎた。人を増やさないと無理。そのためには多少のセキュリティリスクを負っても結果論COMコンポーネント化をするという時代背景に逆らえるというのは、Windows20年の歴史に逆らう覚悟必要

うそ簡単にはかわらないのは、知っている。

だがCOMコンポーネント化はもはや必須

規模がでかくなりすぎた

ただまぁ10年計画だろうね

2020-12-07

コンポーネント化の概念が間違っているデザイナー

なんちゃってコンポーネントみたいな感じで

似てるけどちょっと違う、共通化しようとしても微妙に違って不可能みたいなパーツを大量生産してくるデザイナーが居て困ってる

結局デザイナーは見た目だけそれっぽく取り繕えば良いだけで設計まで考えずに行き当りばったりで作ってる

いわゆるコーディング知識ゼロだけどデザイン知識はそこそこあるおエライサン

今まではシステム無関係な派手派手な単発仕事ばかりだからどうにかなってたけど

今回大規模システム絡んでくる案件でそれやられてしまって頭痛

俺の能力がクソだから仕事が遅い扱いにされてしまってマジでしんどい

2020-10-10

React HookClass置き換えまくるマンツイッターでイキっててイラッとする

内部ステートを持たないコンポーネントファンクションコンポーネントにするのはよく分かる
だけど関数化しておいて内部ステート持たすのに無理やりHookを使う意味マジでからない

いや、関数ステートもたせるってそれクラスでええやろって。
しかファンクションコンポーネント形式で書こうが結局は内部実装ではクラスに書き換えられてるし。

しかファンクションコンポーネントで書いたらprop/state更新されたら常に再描画走るし、Classで使えたshouldComponentUpdateによる細かいパフォーマンスチューニングもできず、せいぜいuseMemoでpropが変わらない時再描画を防ぐっていうだけ

ツイッター見てたら自称上級Reactエンジニアが「会社コードClassコンポーネント見つけたら片っ端からhookで書き換えてる」とかいうクソツイ撒き散らしてて、すげえ吐きそうになった
同じ会社の奴ならぶん殴って喧嘩してると思う

ネットみてるとReact Hook vs Reduxとかいうクソ記事蔓延してるし何なの?Hookローカルステート、Reduxはグローバルステート管理手法であって両者を比べられねーだろ
ネット初心者用のクソ日本語ドキュメントが増えまくったせいでクソエンジニアWebアプリ界隈増えすぎててマジでイライラするわ

2020-09-23

こんなGUIコンポーネントありましたっけ?

っていや

DirectXつかって、オリジナルで書くってのが、

まだあたりまえの時期だったからなぁ

GDIで書くといまいち遅いとおもってな

 

DirectX対応

というだんかいで、お察し

2020-08-26

IT系デザイナーが嫌い

何でWebアプリデザイン知識そこまで無いわけ?

せめて他社のデザインデフォルトコンポーネントなのかトレンドなのか他社独自のものなのかくらい覚えてよ

せめて端末やウィンドウの大きさで表示しなければならないデザインの形が変わるって気づいてよ

せめて状態によって色や見た目が変わるって気づいてよ

何のプロなんだよ

そんなやつばっか

2020-08-06

スレッドを立てるのなら終始ポートを開放しとけっていう意味か?そうだよな。別スレッドを立てたり閉じたり自由にできないのか?今時の.netテクノロジーならできるよな。BackgroundWorkコンポーネントでも研究してみるかな?

2020-07-18

Unityをやろうと思ったけどC#単体でゲーム内部部分を作れない

C#ゲームの"コア動作"部分をちょこっと作ろうと思ったんだけど、なんていうか、コマンドラインで動いて試すライブラリみたいな感じで、Unity経由せずにある程度作るってできないのコレ

Visual Studioの「C#デスクトップ開発するよコンポーネント」ってのをインストールしないとできない?なんか4GBくらいあるんだけどこれ今からやるの?明日なっちゃうよお

2020-07-13

https://qiita.com/acro5piano/items/8395ca9ae878ffcac17f

Qiitaユーザーと言えばド定番の「公式ドキュメント読んですらいない」パターンだと思うけど

QueryコンポーネントもuseQueryフックもrefetchってメソッドを返すので、これ呼ぶとキャッシュ強制更新できます

無駄人生を過ごす前に情報源を精査しようね

2020-07-10

anond:20200710183647

なるほど!!!

https://reactjs.org/docs/context.html

これを使ったらコンポーネント状態を別々に管理しつつも createContext でスコープ自由に作れて、Provider のところで配下コンポーネントに対して DI できる感じ(語彙力。。。)で使えるということですね。圧倒的に便利!!!

ありがとうございます

ログイン ユーザー登録
ようこそ ゲスト さん