  |
はてなキーワード: ソフトウェアとは
呪術回戦やチェンソーマンはガラケーの時代を舞台にしている。20年前ではないが10年以上昔のことだ。この程度なら微妙にノスタルジーを感じる程度の時間的ギャップ。
ちびまる子ちゃんやサザエさんは日常をテーマにして延々と続いて長寿アニメと化したので、微妙なノスタルジーから明確なノスタルジーへと変化し、今では半ば時代劇の様相を呈している。
敗戦後の日本の経済成長期はハードウェアの発展がめざましく、日常空間、生活様式が目まぐるしく変化した。言い換えれば、10年ひと昔がぱっと見でわかる時代だった。
今はソフトウェアの発展は目覚ましいがハードウェアの発展はそうでもない。だから、日常空間や生活様式はぱっと見ではあまり変化が無いように思える。
日常的に英語から直訳された日本語の文章に触れている人々は、そのような文章の持つ特徴的な様式を真似ることができるかもしれません。私は英語話者ではありませんが、それらの様式を用いて書かれた文章をどこか奇妙に感じると同時に、魅力的にも感じます。しかしながら、不運にも、どのようにすればそのような文章を書くことができるのかについて語る人を私は見たことがありません。そこで、私はこれまでの経験から英語から直訳された日本語の文章が持つ特徴を思い出し、それらを箇条書きにしました（それらの特徴は絶対的なものではないことに注意してください：ソフトウェアによる翻訳の精度やあなたが普段話すコミュニティなどによって左右されるでしょう）。
（１）文頭の副詞。驚くべきことに、普段用いられる日本語では文頭に副詞が挿入されることは多くありません。
（２）指示語の多用。「そのような」、「これらの」、などこれらの指示語はあまり使用されません。特に「これらの」など複数のものを指示する語は日常的には殆どお目にかかることはないでしょう。
（３）コロンおよびセミコロンの使用。日本語の文でこれらの記号が使われることはまずありません；私もこれらの意味を正確に理解していません。
（４）長い主語。膨大な修飾句を伴う名詞を主語として用いた文章を日本語の日常会話で用いることは稀です。
（５）体言止め。大きな、しかし細いゴシック体で表示された簡潔なキャッチコピー。
（６）主語の非省略。あなたは「あなた」と頻繁に書かれた文章を日本ではあまり見ないでしょう。
（７）主語の過剰な省略。（６）と合わせてダブル-バインドされます。
私がしたいことは翻訳の精度の低さをあざ笑うことや「奇妙でない」日本語を称揚することではありません。むしろ、他愛もない話の種の共有、そして裏を返せば日本語を他の言語に翻訳する時も同様の奇妙さと魅力が生じているかもしれないこと、しかしいかなる重要な問題も生じていないことの示唆が私の目的です。上述の7点を覚えていても（覚えていなかったとしても）、あなたの言語活動が楽しいものになることを願っています。
保険料率が上がった原因はIT業界の高齢化ではないよ。病気がちの組合員を減らしたところで全体への影響は軽微だ。
令和5年度と令和6年度を見比べると、支出のうち「前期高齢者納付金」が100億円アップ、「後期高齢者支援金」が80億円アップしている。
これは日本中のジジババのために各保険組合が払わされる金だ。この負担が年々増えていくので保険料率は今後もどんどん上がるだろう。
また、収入に目を向けると「繰越金」「繰入金」が激減しているのがわかる。
これはITS健保がいままで潤沢な収入や資産をもとに組合員の負担を抑えられていたのが底をついたことを意味する。
関東ＩＴソフトウェア健康保険組合は高齢化した会社、障害者になった社員を抱えている会社をパージしろ！！ 値上げなんてしてんじゃねぇ、なんで見知らぬ弱者に金出さなきゃならんのだ
こっちもリストラして会員になったんだぞ
ボイジャー１号の問題が１つのチップに起因することを突き止めたＮＡＳＡのチームは、コマンドを送ってコンピューターシステムの再起動を試み、根本原因を探ろうとした。
３月１日にコマンドを送ったところ、同月３日になって、飛行データシステムの一部に、解読不能なデータとは違う挙動があることを発見。この信号は、飛行データシステムが正常に機能しているかどうかを判断するために使っていたそれまでの形式ではなかったものの、ＮＡＳＡのディープスペースネットワークで解読することに成功した。
この内容を調べた結果、問題の原因が判明。飛行データシステムのメモリの３％が破損していたことが分かった。システムのメモリの一部を保存していたチップが、同コンピューターのソフトウェアコードの一部も含めて正常に作動していなかった。チップの不具合の原因は不明だが、劣化した可能性や、宇宙空間からのエネルギー粒子が衝突した可能性が考えられるという。
科学データと工学データの解読ができなくなったのは、このチップに保存されていたコードの損失が原因だった。
このチップを修理する手段がなかったことから、同チームはこのチップに保存されていたコードを同システムのメモリの別の場所に移すことにした。全てのコードを保存できる区画は見つけることができなかったが、コードをセクションに分割して、それぞれ飛行データシステムの別々の場所に保存することに成功した。
計画を進行させるためには、こうしたコードのセクションが引き続き全体として機能することなどを確認する調整作業が必要だったとＮＡＳＡは説明する。飛行データシステムのメモリの別の部分で問題のコードの場所を参照している箇所も更新する必要があった。
ボイジャー１号の工学データのパッケージ化に必要なコードを見極めた技術者は、同システムのメモリの新しい場所を指し示すコードを４月１８日に送信。この信号がボイジャー１号に届くまでに約２２．５時間、地球に反応が戻ってくるまでにさらに２２．５時間を要した。
２０日、ボイジャー１号から届いた反応は、コードの修正が成功し、再び解読可能なデータを受信できる状態になったことを表していた。
その瞬間、ＮＡＳＡのジェット推進研究所は拍手と歓声に包まれた。
今後も同システムのソフトウェアの問題が起きた部分を別の場所に移す作業を継続し、数週間後には科学データを受信できる見通し。
「ボイジャーにこれから何が起きるかは分からない。それでも飛行を続けて私たちを驚かせ続けている」「数多くの異常が発生して次第に困難になっている。それでもこれまでのところ、幸運にも復旧できた。ミッションは続く。若いエンジニアがボイジャーチームに加わってその知識を生かし、ミッションを継続させている」。ボイジャーのプロジェクトマネジャー、スザンヌ・ドッド氏はそうコメントしている。
# ヨーロッパの主要都市におけるソフトウェアエンジニア向けベストカンパニー
ヨーロッパの各都市でソフトウェアエンジニアにとって最適な企業を探しているなら、以下のリストが参考になるでしょう。
Google, Facebook, Snap, NVIDIA, Microsoft, Apple, Oracle, Snyk, GetYourGuide, UBS, Swisscom, DFINITY, Cisco.
Google, Facebook, Snap, Jane Street, Stripe, Coinbase, Apple, Amazon, Hudson River Trading, Citadel, ByteDance, Two Sigma, Palantir, Bloomberg, Revolut, GSA Capital, Marshall Wace, Quadrature, Five Rings, G-Research, Starling, Personio, DeepMind, DRW, Millenium, BlackRock, MAN Group, Jump Trading, DE Shaw, AQR, Maven Securities, Point72, IMC, Optiver, Susquehanna (SIG), XTX, Old Mission, Squarepoint, Qube Research & Technologies (QRT), Yelp.
Uber, Databricks, Bitvavo, Booking, Miro, Flexport, Atlassian, Spotify, Optiver, IMC, Amazon, Adyen, Google, Stripe, Flow Traders, MessageBird, Reddit, Box, JetBrains, Personio, Elastic, GitHub, Catawiki, Tower Research, Radix Trading, Headlands Technologies, Tomtom.
Google, Meta, Datadog, Criteo, Microsoft, Stripe, Airbnb, Amazon, Atlassian, Hubspot, Workday, Ankorstore, Red Hat, Algolia, Alan, 360Learning, ContentSquare.
AWS, Amazon, Microsoft, Wayfair, Google, Meta, Apple, HubSpot, Stripe, NVIDIA, Snowflake, Personio, Databricks, JetBrains.
AWS, Microsoft, Google, Mastercard, Workday, Salesforce, Meta, Stripe, VMware, LinkedIn, Etsy, Personio, ByteDance, Coinbase, Hubspot.
Google, Apple, Microsoft, Nvidia, Adobe, Workday, Celonis, BMW, Salesforce, SIXT, SAP, Huawei, Personio, Intel, JetBrains, IBM.
Google, Snowflake, Netflix, Pinterest, Rippling, Oracle, Waymo, AMD, Samsung, NVIDIA, Box, Warner Bros, Visa, Amazon.
Amazon, Apple, New Relic, Stripe, Rippling, Revolut, Skyscanner, Microsoft, N26, Criteo, Adobe, Thoughtworks, Oracle, Glovo, Personio.
Apple, Amazon, Roku, Arm, Microsoft, Qualcomm, MathWorks, AMD.
Amazon, Oracle, Microsoft, Flutter, Unity, Skyscanner, Huawei.
Databricks, Microsoft, Nutanix, Rivian, Foursquare, Yandex, JetBrains, Nordeus, Luxoft.
Amazon, Datadog, Microsoft, Apple, Google, Personio, Twilio, Glovo, VMware, Meta, Oracle, Revolut.
Klarna, Spotify, Netlight, PayPal, Ericsson, Ubisoft, Warner Bros, King, Google, Oracle, AWS, Microsoft, Wolt.
Google, Rippling, Oracle, Revolut, Uber, Amazon, Deliveroo, IBM, Splunk.
Crowdstrike, UI Path, Google, Adobe, Stripe, Microsoft, Oracle, IBM, Amazon, Electronic Arts (EA).
Microsoft, Maersk, Zendesk, Workday, Unity.
Productboard, Pure Storage, Apple, Workday, Oracle, Microsoft, JetBrains, Proton, Parrot.
Bolt, Wise, Microsoft, Twilio, Wolt.
Microsoft, Cisco, Aker Solutions, Arm, Mastercard, Meta, Kahoot, Autostore, Remarkable, Netlight.
これらの都市は、ソフトウェアエンジニアにとって多くの機会を提供しています。それぞれの都市が提供する企業は、エンジニアが自身のキャリアを発展させるための多くの選択肢を提供しています。それぞれの企業が提供する機会や文化は、エンジニアが自身のキャリア目標に合わせて最適な選択をするのに役立ちます。 [
無料で読みたいならググり散らかせよ
あらゆる言語あらゆるソフトウェアを使いこなしてネットのどこかには必ずあるものをぶっこ抜く能くらいつけてみろ
そうやってネットユーザーは賢くなっていくんだよ
人類学者であるデヴィッド・グレーバー氏は、現代社会において多くの仕事が無意味であり、社会にとって価値を生み出していないと主張しています。2018年に出版された著書『ブルシット・ジョブ：クソどうでもいい仕事の理論』の中で、彼はこのような「ブルシット・ジョブ」の存在について論じています。
グレーバー氏は、以下の特徴を持つ仕事が「ブルシット・ジョブ」であると提案しています。
企業法務、テレマーケティング、広報、一部の管理職などが、「ブルシット・ジョブ」に該当する可能性があります。これらの職業は、必ずしも社会に貢献していないと断言することはできませんが、その価値が明確に見えにくい場合が多いと言えます。
粗雑なコードを修正するプログラマーは、「尻拭い」のカテゴリーに分類される可能性があり、以下のような問題に直面しがちです。
このような状況下でプログラマーは、本来創造的な活動であるはずの新しい価値を生み出す作業ではなく、過去の過ちの修正に追われることになります。これは、ソフトウェア開発プロセス全体に大きな問題があることを示唆しています。
元増田で「レジ担当の人間を雇う」代わりに「人間より維持費の安い機械を先行投資で買う」というトレードオフが語られていないのがそもそもの問題では？
一括やリースで機械を設置する即金が無いならトータルコストが高くてもレジ担当を雇うのがベストエフォートになるはず
通過側で下手に互換性を設けるとそれ自体が脆弱性になることは自明なんだから
逆に紙幣判別機へUSBのような共通規格を制定して安価にモジュール交換できるような法案を設けた方が建設的では？
USBのように接続端子の形状さえ統一しておけばソフトウェア側で吸収できるんだし何十年もかけて紙幣に互換性をとか悠長な話でもなくなる
前提条件を見直した方がいいよ
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。
10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。
■前提
・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
結論としては書かないほうがいいと思った。
・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。
・テストコードを書くと実装の見落としが見つかってありがたいことはあった。
・git pushするたびに毎回走っても全くの無意味だった。
・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。
・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。
・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。
・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
一方、僕が集めてきたプログラマーはプログラミング未経験の頭の良さそうなネットゲーマーだけです。
なので初期のドワンゴは、森さん率いる天才ハッカー集団からなる超強力な開発チームと、僕の率いる廃人ゲーマーによる即席プログラマーメインの弱小開発チームの二つからできてました。
僕と森さんで最初に考えたドワンゴのビジネスモデルは単純で、優秀な僕ら（といっても森さんチームだけですが）は控えめにいっても普通の開発会社の半分以下の工数でソフトウェアを開発できる。
なので、実際にかかる工数の2倍で見積もりを出せば、半分は利益で丸儲けのはずだ、というものでした。
とても簡単な算数ですが、後から振り返るとそこが「理系のずるさの限界」でした。
僕らはドキドキしながら2倍の見積もりを出したんですけど、本当は10倍ぐらい出すべきでした。じゃないと儲からない。実際は想定よりも工数がかかることがあり、2倍じゃ利益出なくてめちゃくちゃ大変です。
ドワンゴが大きくなってから当初のドワンゴぐらい実力があって良心的な下請けが欲しいと、心から思いました。当時のドワンゴが出してた見積もりのさらに2倍の金額払っても、同等の仕事をしてくれる下請けなんて、なかなか見つかりません。
でも、文系経営者の中には平気な顔して100倍の見積もりとか出せる人もいたんですよね。僕らの感覚ではもはやそれは詐欺で、とてもできない。
神経ネットワーク自体は同じでも、ネットワークの上を走るソフトウェアに違いがある。
それがその謎の答えだと思う。
読んでもらえれば分かると思うんだが、違法どころか不徳ですらないんだよ。
西洋人的な考え方をエミュレーションできれば分かると思うんだが、Webとは本来自由なものであるべきで、現在の広告のあり方というのは商業的な発展の至らなさから未熟な形で無理やり御仕着せられているものにすぎない。
受け入れがたいものを拒否できることは、尊ばれなきゃいけない。企業のような特定の商業的権威が「正義」を作り出す側であってはいけない。インターネットシチズンのものでないとね。
仁義みたいな関係性の概念を重視しすぎて、人間の根源的な理念を蔑ろにしがちな東洋人的発想は、権威を肥大化させ、独裁者を生み出しやすいとも言える。
ダメなものは正しく拒否していくことで、Web収益化がより妥当なやり方へと改善されていく方向へと圧をかけて、進歩を後押ししていくことにつながる。
逆に、嫌な部分があっても恩があるから盲目に受け入れることを続けていると、悪質な商習慣に蝕まれる人々をいつまでも生み続ける悪循環に加担することになってしまう。
ソフトウェアは「割れ」で入手されてしまうから、「割れを使うな！」といくら倫理を振りかざして叱った所でダメで、結局提供側が、Webサービス(クラウド)化したり、サブスクにしたりすることで、ソフトウェア販売方式の常識がアップデートされてきた。
そういうのが分からないくらい車オンチがTesla乗ってるから、いかに質が低い車乗ってるか分からないんだよね。
TeslaやBYDに試乗してみると「おっ、頑張ってはいるけど、乗り心地や建て付けは値段の割にいまいちだよね」というレベルでしか無い。
ロールスロイスとまで行かなくてもまともな高級車乗ったら質の高さと違いがありすぎて普通はビビるけど、EVワナビーみたいな鈍感な馬鹿には理解できないんだろな。
車なんて安全性が全てだから、Tesla信者のワナビーがよくひけらかすOTAや運転支援、インフォテイメント、タッチパネルのみの操作性とか、目眩ましでしかないんだよね。
OTAみたいなオンラインソフトウェアアップデートにしろ、安全性高くないと危険でしかない。
Teslaみたいに走行機能までまともにテストせずにアップデートするようなやり方だと運転支援で事故も起きる。
運転支援にしろ、LEXUSやBMW、日産と比較すると恐ろしく運転が下手で初心者かな？みたいな運転レベルだし、
いつまで経っても他社ではできてる手放し走行ができないのにも目をつぶってる。
インフォテイメントや操作性なんかは詳しく書かないけど、いかに安全に作り込むかという世界なのに、
Teslaはそれぞれがまともに作れていないし、先進性ありそうなEVというだけが売りだから、どんどん抜かれている。
BYDも車乗らない奴にはよく出来ているように感じるのだろうけれど、操縦安定性がポンコツだし、
インフォテイメントの変なとこばっか頑張っていて、そもそも運転支援はTeslaよりもゴミ。
アレに金出すなら、軽買った方がマシなレベルなんだよね。
