  |
はてなキーワード: コードとは
独り暮らしの為の家電について、2024年5月現在の決定版をだらっと書く。
一人暮らし向けの冷蔵庫は、インバーターが搭載されていないものが多い中、こいつはインバーターが搭載されたことにより、以前のモデルに比べて飛躍的に静かになった。
インバーター非搭載の冷蔵庫は、コンプレッサーの運転時に「全力かオフか」みたいな昭和かよ。みたいな挙動しかしてくれないので、「バゥーーーーンンンン」っていうアホみたいな音が断続的にする。ワンルームで朝昼夜この音とずっと一緒なのはきついよね。私はきつかった。
インバーターのおかげでコンプレッサーを良い感じに動かすという、ようやく平成かよ。という挙動（褒めてる）を行ってくれるのがこのNR-B18C1なのだ。
メーカーさん、「ワンルームって部屋が狭くて冷蔵庫が近いのに、ワンルーム向けの冷蔵庫、うるさくね？」って気が付くのに何年かかってんだよとしか言いようがないが、みんなが買わないと多分そのうちなくなっちゃう。困る。この灯を絶やしてはいけない
これより一回り小さいモデルとして、同じくインバーター搭載で容量156リットルのNR-B16C1もあるが、横幅は同じなので、より大きいNR-B18C1をお勧めしておきたい。
掃除機はこれ。
PV-BS1Lの良いところはあれだ。まず圧倒的に軽い。1キロ切ってる。軽さは正義だ。
充電台が無い。充電台が無いのはメリット。はっきり言って充電台は邪魔だ。コードを本体にぶっ指せば充電開始だ。あ、良い感じの部分にゴムのすべり止めが付いてるから、本体を壁に立てかけても倒れないよ。えらい
ワンルームなんてクイックルワイパーで十分って？わかる。ぶっちゃけクイックルワイパーの標準＋ウェットのコンボで床面はほぼ攻略できる。だけど、ちょっと違うんだ。
こいつは延長パイプを外してハンディタイプとして使う時に、吸い口に可愛いブラシがちょろっとついている。これが便利なんだ…。キーボードも、窓枠も、気になるあの部分この部分をこの小さいブラシで掻き出しつつ吸いまくれ。
さらに別売りファブリックヘッドPV-BL30J-005 を使えばベッドの掃除も完璧だ。ぜひベッドや布団を掃除機で吸ってみて、ダストカップに溜まる謎の細かいチリに戦慄してほしい。
というかメーカーさん、掃除機は布団用の掃除口は標準でセットで売ってくれても良いと思うぞ。
後こいつはダストカップも水洗いできる。精神的にかなりすっきり。
掃除機にうるさいそこのあなた、言いたいことはわかるよ。私だって、紙パック式の捕集率99.999％（大きさが0.3～10マイクロメートル）の掃除機(キャニスター)や、ダイソン(これまたキャニスター)も継続的に使ったことがある。
でもね、一人暮らしの紙パック式は、その掃除面積の狭さとのせいで紙パック交換の頻度が低下しちゃって、結果毎回捨てるサイクロンの方が衛生面で有利になっちゃってね。。。
ダイソン？あれは水洗いできねぇ。ダイソンが誇るルート サイクロンテクノロジーに基づいて製造されたサイクロン内部にこびり付くかの如く永遠に溜まり続けるゴミ、チリが気にならないのなら良いかもしれないがな…
洗濯機について書こうとしたところで力尽きた。
いい区切りだったので乱文になるけど吐き出させてほしい
8年ほど前、まだ20代後半だった自分が今の会社に中途採用された際に同時入社の同期が１人いた
自分とは歳の離れた40代後半であった同期である彼こそが後に、時限爆弾を仕掛ける人物である
入社した会社はその時期に基幹システムの刷新を考えていたらしく
その募集でシステム部として採用されたのが自分とその同期であった
当時のシステム部の社員は2名体制で1人が60代で定年間近の上司A、もう一人は50代の上司B
2人でなんとか基幹システムの維持だけを行っている状態であった
会社としては基幹システムの刷新以外にも社員の世代交代を徐々に行っていくための採用だったと入社直後に言われた記憶がある
60代の上司A、50代の上司B、40代の同期、そして20代の自分
確かにそのまま行けば年齢層は順調に推移して、10年単位で20代を採用することを繰り返せばいい感じにも思えた
入社してからの仕事としては60代上司Aの定年退職が控えているため、まずは稼働中の基幹システムの仕様理解に日々の業務の引継ぎ
そんな多忙な業務をこなすなか同期と話すうちに彼の人柄が徐々にわかってきた
箇条書きでまとめるとこんな感じだったと思う
・今の会社に採用される前、同じような職を転々として現在8社目であること
・受託システム開発ばかりやっていたが、そろそろゆっくり仕事ができる社内SEでまったり過ごしたいこと
・年齢と経歴の割にプログラムが雑なこと（※これは自分視点だがそう的外れではないと思う
また、今の会社に対してのスタンスや不満が溜まってきていることも伝わってきた
・システムを作る自分たちのチームが上で、運用するチームを下だと見下していること
・その運用チームから稼働テストの際にミスを指摘されると不機嫌になること
中々怪しい気配が漂ってきたと当時の自分は思った
残業に関しては、毎日という程ではないが20時頃までは働いていたと思う、遅くても21時までだったはずだ
ただこれはシステムの刷新が終わるまでという明確なゴールがあったのでそれまでは申し訳ないが対応してほしいと事前に説明があったし残業代もきっちり出ていた
自分は前職が完全にブラックで終電帰り、残業代なしが当たり前という環境もあったため特に問題なく仕事ができていたが同期はかなりストレスだったようだ
給料については会社の方針として勤続給ではなく年齢給であったため同時入社であるものの同期は自分よりかなり貰っていたはずであるが、それでも不満だったようだ
トラブルといってもただ上司Bが打ち合わせ中の同期の態度について不真面目だと切れて説教したのだ
この上司Bと同期の彼は相性が悪いようで度々小さな衝突はあったが上司Bが声を荒げて説教するのは始めてのことであった。
しかしこのことがきっかけで上司Bは同期に対して我慢がきかなくなったのかこの後もおよそ2ヶ月に1度のペースで業務のミスといったことから朝に挨拶をしなかったといった細かいことまで説教は続いた
この状態に嫌気が差した同期はある時を境にプライベートの予定があるからと基本残業はしなくなった
たまにどうしても必要がある際は業務命令という形で残業を依頼していたが、それでも19時くらいまでであった
しかし同期はそれもかなり不満だったらしく
残業した日は会社の最寄り駅と会社の間にあるビジネスホテルに泊まり
翌朝、ホテルの前を出勤中の社長や役員の前を偶然を装ってチェックアウトして遭遇し上司Bが無茶な残業を強要するせいでホテルに泊まる羽目になったとアピールするということもあったという
そのため、ちょくちょくシステム部にたいして過度な残業に関する指導が入っていたと後に上司Aから聞いたことがある
そして入社からおよそ3年が過ぎ、なんとか新システムも完成に近づいた時
しかしこの時は同期も相当機嫌が悪かったのか、それとも今まで積もり積もったストレスが限界だったのか、もしくは両方か分からないが
上司Bも同期もお互いに売り言葉に買い言葉で収集が付かず、上司Bが一旦頭を冷やすといって席を離れた際に同期はPCを少しいじると私物をまとめ無断で早退として帰っていった
なおこの時、上司Aは有給で休み、自分は電話応対中であったため止める者がおらず気がついたら終わっていたといっていいスピード感だった
そして同期は翌日、人事部に退職すると電話するとその後出社することはなかった
新システムの作成中データを取り出すために起動したがそれ以降はそのまま一度も起動することなく放置という状態であった
上司Bは撤去したい様子ではあったが、ある役員から戻って来るかもしれないからとりあえずそのままにしておくようにと指示があったので触れることもしなかった
その後、同期の担当分を自分が引継ぎ新システムの作成にとりかかるが彼の担当していた機能はなんとなく察してはいたが、かなり雑な作りな上
運用部門の要望をまったく聞かなかったため、とてもリリースできる状態でないことが発覚
改めて要望に沿った形で修正をする方針で進めると彼が作成したコードで残った部分は30％も残らなかった、ほとんど作り直しと言っていいレベルだ
そのときには定年から雇用延長となっていた上司Aは区切りがついたと退職
会社の業績もあまり安定しない時期でもあったため追加人員の採用は見送られシステム部は上司Bと自分の2名体制となった
その際に新システム作成が評価されたのと2名体制で苦労をかける事情からか自分は課長に昇進した、4年目のことである
新システムはその後、小さなトラブルはあるものの順調に稼働を続ける
なお小さなトラブルの大半は同期の彼が作った部分が関わっていることが多く
その度に彼が作ったコードは修正され、今では機能の殆どに彼のコードは残っていない
残っているのはせいぜい彼が名付けた関数名や変数名くらいである、中身はもう別物だ
そして6年目のある日、上司Bが突然亡くなった
腹痛を訴え病院へ、で即入院してそのまま復帰することなくという形だ
癌だったらしい
その時の会社の上層部はかなり大慌てであったらしいがシステム部としては正直あまり変わりがなかった
というのも新システムを作る際に運用部門の要望をほぼ取り込んだ結果
システム部の基幹システムに関する仕事はほとんどなくなったといっていいレベルとなったのだ
しかし周りはそうは思っていないらしく、システム部は1人しかいないのだから極力負担をかけないようにと各部門には通達がいったらしい
しかし実態はあれだけ忙しく残業していた日々が嘘のように毎日定時で帰っても問題ないのだ
同期の彼が望んでいたゆっくり仕事ができる環境がここに完成していた
そんな中、同期のPCを残しておくよう指示を出した役員も退職する時期となり
そこで改めてPCを起動して中をいろいろ確認していったのだが、そこであることに気づく
起動回数は1回限りで未実行、起動予定はかなり過去の日付が指定されており、とっくにその日付は過ぎていた
バッチ処理の内容を詳しく見てみるとPCの全ドライブの消去コマンドが書かれていた
同期の嫌がらせだったらしい
起動予定の日付を良く確認すると彼が退職を連絡した日の翌月が指定されていた
しかし実際は彼が退職した翌日以来、PCを起動した事はないしバッチも動作していない
※今回は不発だったから良いけど実際にやると損賠賠償になるから
このことは報告していないが、業務でバッチ処理に関わる度に同期のことを思い出す
もし彼が残っていたら昇進したのは自分ではなく同期となり、彼の言う満足いく給料を貰えたかもしれない
もし彼が残っていたら上司Bがいなくなりストレスがない職場で彼は働けたかもしれない
もし彼が残っていたら運用部門からの要請はなくなり、残業とは無縁な仕事が出来たかもしれない
いや最後のは無理かな
作ってたコード雑だったし、人の話聞かなかったし
ふと彼のその後が気になって調べてみたことがある
世間話で同期がSNSをやっていると聞いたことがあり検索してみたのだ
アカウントは知らなかったが彼の話していた世間話の内容で検索してみると意外なほど簡単に見つけることができた、アイコンも自身の顔写真にしており間違いないと思われた
また次（の次？）の職場で残業がらみのトラブルを起こした愚痴が書いてあった
うちの会社を退職したときの事は何を書いていたのか過去の在職期間の投稿を見てみると大半は案の定愚痴の羅列が並んでいた
そして、その連続した投稿の中で退職直後の時期に面白い投稿があった
要約するならこうだろうか
社内システム作っている自分に無茶ぶりばかり、データ全部消去して退職してやった
直してくれと謝罪の連絡してももう遅い、既に新しいホワイトな職場でまったり仕事中です
彼の中でうちの会社は有用スキルを持った人間を無能と決めつけ追放したギルドのように写っていたらしい
しかし実際はデータ削除の時限爆弾は不発であったし、仮に成功していても
現在彼の書いたコードはほぼ残っていないから直してくれと依頼することもない
そして彼の新しい職場は現在のSNSの投稿を見るに彼基準ではホワイトな職場ではないと自白をしている始末だ
ところで実際彼に連絡した人がいたのかという話だが
上司Bは既に亡くなっているので分からないが、おそらく連絡はとらなかっただろう
彼が退職の連絡をしてきた後、残っていた有給を消化したくらいのタイミング（大体1か月後）で退職に伴う書類の送付先の確認で何度か電話をしたが繋がることはなかったという
どうやら彼はこの連絡を会社からの謝罪の連絡だと思っていたのかもしれない
今日は入院している祖母に会いに行く日だ。入院前はもう呆けて風呂も入らないぐらいひどい状態だったが、入院してからはちゃんとしているらしい。
それはそうと、lispでpython環境を構築する話だが、結局オートコンプリートはうざいし、使う機能といったらautopep8とisortぐらいなので、以下を.emacsに組み込んだ。
(defun python-autopep8-and-isort () "Run autopep8 and isort on current Python buffer." (interactive) (when (eq major-mode 'python-mode) (shell-command-on-region (point-min) (point-max) "autopep8 - | isort -" nil t))) (with-eval-after-load 'python (define-key python-mode-map (kbd "C-c C-r") 'python-autopep8-and-isort))
.emacsファイルには他にも様々な設定を付与したが、ここではコードを書ききれない。
さてそういうわけで週末コーディングが趣味としてちゃんと機能することはわかったが、毎週作るとなると、いくつも何かを作るよりは一つのタフなものを作りたいと思うわけである。
それで、最有力候補は「Elasticsearchのようなものをpythonで実装する」という話がある。
Elasticsearchが徹底された設定外部化によってjsonを多用するのだが、これがあまり柔軟性がないので、コードを直にいじれるようにしたいと思ったためである。
例えば自作の日本語トーカナイザを組み込みたいときElasticsearchプラグインをJavaで書かなければならない。私はJavaが嫌いであり、プラグインを「インストールする」という手順も冗長に感じる。
それよりはpythonで作られた検索システムに、適当なトーカナイズ関数を実装して呼び出すことができればかなり柔軟であるように思うわけである。
難しい点があるとすれば、大規模分散システムへの対応で、金をかけなければそういうシステムをテストすることができない。
できるだけ金をかけずに趣味をやるというのがモットーなので、これではまずいわけである。
まあ何事も困難というものはある。まずは手を動かすことが重要だ。Linus Torvaldsも"Talk is cheap, show me the code"と言っているではないか。
この手順は、Latent Diffusion Modelsを使用してテキストから画像を生成するための一般的なアプローチを示していますが、いくつかの誤りや欠落がある可能性があります。以下にいくつかの修正と補足を示します。
1. **ライブラリのインポート**: `diffusers` ライブラリは存在しないため、代わりに `torch`、`transformers`、および `diffusion` ライブラリを使用する必要があります。
```python
import torch
from transformers import AutoModelForSeq2SeqLM, AutoTokenizer
from diffusion import LatentDiffusion
```
2. **環境のセットアップ**: 事前学習済みモデルとトークナイザーを使用する前に、必要なモデルとトークナイザーをダウンロードする必要があります。
```python
model = AutoModelForSeq2SeqLM.from_pretrained("nlptown/bert-base-multilingual-uncased-finetuned-xnli")
tokenizer = AutoTokenizer.from_pretrained("nlptown/bert-base-multilingual-uncased-finetuned-xnli")
```
3. **テキストプロンプトの前処理**: `encode_plus` メソッドを使用して、入力をトークン化し、テンソルに変換します。
```python
inputs = tokenizer.encode_plus(prompt, return_tensors="pt")
```
4. **Latent Diffusion モデルの定義**: `diffusion` ライブラリから `LatentDiffusion` をインスタンス化する際に、モデルとトークナイザーを渡します。
```python
ldm = LatentDiffusion(model=model, tokenizer=tokenizer)
```
5. **画像の生成**: `generate` メソッドを使用して画像を生成します。
```python
image = ldm.generate(inputs)
```
6. **生成された画像の可視化**: 画像を表示するために適切なライブラリを使用します。例えば、Matplotlibを使用して画像を表示できます。
```python
import matplotlib.pyplot as plt
plt.show()
```
曖昧な指示をされたとき（コミュニケーションコストがストレス）
納期が短いのにタスクの切り方がざっくりしすぎてるとき（終わらないよ）
修正の仕事で設計書が更新されてなくて、コードを見たらスパゲッティコードで読み解くのが難解だったとき（読み解くのに脳みそが焼ききれて鬱になるよ）
修正対象としたけど、その機能の使い方が誰もわからなくて、あとから今はもう使われてない機能だから対象外としていいと後で言われたとき（消せやそんな機能紛らわしい）
用語をググっても出てこない業界の基幹システムの改修案件のとき
定時後は45分休憩時間の現場だったとき（作業してたから、45分の労働として残業代つけていいか聞いても駄目だと言われたとき）
4月も終わりだが、
未だにエンジニアに微妙な性能のPCを使わせる会社があることに驚きだった
メモリは16GBや8GB
ちょっとした操作のたびに待ち時間が入るだけでどれだけ効率が悪いと思ってるのか
いつまでも古い開発環境しか使ってない人は困ってないらしいが、なぜそれに合わせる必要があるのか
そりゃIDEレベルのものを使わずほぼメモ帳レベルのでコードを書いてれば性能はいらないし、
分解すれば保証なくなるのでは？
BTOで最初からカスタマイズすればいいのに、なぜ出来合いの安いPCを買って交換が必要なのか
そりゃちょっと安いのだろうが交換する作業にかかる時間の時給計算もできないのか
はい、JavaScriptによるコーディングはコンピュータサイエンスの一部と見なすことができます。コンピュータサイエンスは、情報とその処理に関する学問であり、プログラミングはその重要な要素です。JavaScriptは、ウェブページを動的にするための主要な言語の1つであり、ウェブ開発の分野で広く使用されています。したがって、JavaScriptを学び、それを使用してコードを書くことは、コンピュータサイエンスの実践的な応用の一部と言えます。しかし、コンピュータサイエンスはプログラミングだけではなく、アルゴリズム、データ構造、ネットワーク、データベース、人工知能など、より広範なトピックをカバーしています。それぞれが特定のプログラミング言語やツールを使用して探求されることがあります。JavaScriptはその一部であり、特定の問題を解決するためのツールとして使用されます。それはコンピュータサイエンスの一部であり、その全体ではありません。それでも、JavaScriptをマスターすることは、コンピュータサイエンスの重要なスキルを習得するための素晴らしいステップです。それはあなたが複雑な問題を解決するためのロジックとアルゴリズムを理解するのを助け、あなたの思考を開発するのを助けます。それはまた、あなたがウェブ開発の世界に足を踏み入れ、あなた自身のウェブサイトやアプリケーションを作成するのを助けます。だから、はい、JavaScriptによるコーディングは確かにコンピュータサイエンスの一部です！
はい、ブラウザの実装は確かに**コンピュータサイエンス**の一部です。以下に、その理由をいくつか挙げてみます：
1. **アルゴリズムとデータ構造**：ブラウザは、効率的な検索、ソート、データの格納と取得など、多くのアルゴリズムとデータ構造を使用します。
2. **ネットワーキング**：ブラウザは、HTTPやHTTPSなどのプロトコルを通じてインターネットと通信します。これらのプロトコルの理解と実装は、コンピュータサイエンスのネットワーキングの分野に直接関連しています。
3. **レンダリングエンジン**：ブラウザのレンダリングエンジンは、HTML、CSS、JavaScriptなどのコードを解析し、それをユーザーが見ることができる視覚的なウェブページに変換します。このプロセスは、計算理論、グラフィックス、プログラミング言語の理解を必要とします。
4. **セキュリティ**：ブラウザは、ユーザーのデータを保護するために、さまざまなセキュリティメカニズムを実装します。これには、暗号化、サンドボックス化、同一生成元ポリシーなどが含まれます。
これらすべての要素は、コンピュータサイエンスの基本的な概念に基づいています。したがって、ブラウザの実装は、その「サイエンス」の部分を明確に示しています。ブラウザの設計と実装は、これらの理論を実際の製品に適用するための実践的なフレームワークを提供します。それらは、問題解決、効率的な設計、そして最終的にはユーザーに価値を提供するための方法を探求します。これが、ブラウザの実装がコンピュータサイエンスである理由です。
俺のエスパーがあってればだけど
超初心者向けの環境の構築とかHello Worldとか If forとかはあるけどそっから実際に何か作るところが薄くて、飛んでオライリーでリーダブルコードだのDDDだのっていうことなのかと
時々、行動を起こすことが重要だと思うことがある。
私は障害者であり、ハロワの職員に勧められて自立訓練施設で訓練していたことがあった。そこでの人間関係は楽しいものだったが、訓練が役立ったことはない。
教えられなくとも料理はできるし、裁縫を学んでも実生活で役立つことはないし、OfficeSuiteの使い方なんてものは教わるまでもない。
訓練の一環と言って、無賃で工場勤務をしたこともある。たまに巨大組織に金をむしり取られる夢を見る。これは自立訓練で金と時間を奪われたトラウマと思っている。
「足るを知る」がその組織の哲学だったが、個人の哲学として優れているとしても、企業がそれをやれば「低賃金？障害者のお前たちが働けるだけありがたく思え」という態度になるだろう。
それで...行動を起こすとはどういうことか。例えばそれは自立訓練を抜け出して自分の力で転職活動をするということだ。そして結果的にフルリモートで働くプログラマーになれたわけである。
さてこの先、収入を高めるために転職活動をするべきだろうか。私は箴言の一句を思い出す。
フルリモートで自由度が大きいのに、仕事に対する態度がかなり真面目になってしまい、精神的にもストレスは溜まっている。
真面目に働こうと思うわけである。GWも火曜日からは仕事がある。
ところで、仕事と余暇が同じ部屋であるからか、寝ているときにコードを脳内で走らせるような悪夢も見る。
おそらく代わり映えのない部屋の風景に浸り続けるのがいけないのだろう。今日は散歩でモスバーガーまで行ったが、こういう気晴らしが必要だ。
休日の散歩コースのバリエーションを増やしてみるのがいいかもしれない。見慣れていない自然の景色を見に行ってみるか。
新人エンジニア社員が現場のベテラン業務委託に話を聞いてもらえないとか、
テスターがエンジニアに話を聞いてもらえないとかいう話をよく聞くけど、
俺は新人の時点でそこそこコード書けたし、エンジニアの割にはコミュ力もある方だったから、実力で一目置かせて現場と仲良くなってた。
ついでに、はっとするような指摘をくれるテスターには逆に一目置いてる。
もちろん明らかに邪険にするような態度を取るのは社会人としてNGなんだけど、実力主義の職種なんだから人のせいにしてないでコミュ力含む自分の実力磨けよなという話。
従来プログラミング業界においては、やれ「ググる力が重要」だの、やれ「分からないことはググればいい」だのと言われてきたわけだが、もうそろそろこういう妄言は根絶されるべきだ。
そもそも、専門知識の要る分野でそれなりの水準の仕事をしようと思えば、ググって済むようなことはほとんどない。
実際、プログラミング以外のあらゆる分野で「ググればいい」なんて言われることはほぼ無い。その分野の仕事に必要な基礎知識を身につける方が圧倒的にウェイトが高いからだ。
「ググる力」とか言ってるアホは、じゃあためしに俺の手元に、タネンバウムの「コンピュータネットワーク」第6版があったから、これと同等の知識を、コーディング時の調べ物だけで身につけてみてくれないか。
こんな知識は業務で必要ない？そりゃお前がその程度の仕事しかしてないってだけだろ（笑）
ネットのサンプルコードコピペするしか能のないIT土方、コンピュータサイエンスや数学にコンプレックス持ってる低学歴は、さっさとエンジニアやめろ。少なくとも、他人（とくにプログラミング初学者）を自分と同じ水準に貶めるな。
まず挙げられるのが、何でもかんでも言わなきゃやらない指示待ち無能への揶揄である、ということ
オブラートを剥ぐと、その程度のこと自力でやれカスが、であるがそんなこと言うと社会人として終わってるのでオブラートに包むのである
つぎにそこまでは無能ではないが初心者へアドバイスとして述べられるパターン
こちらは単純、元増田にも触れられてるが専門知識で調べても出てこない部分はどうしても出てきてしまう
ただしここで重要になるのは直面したその問題が、調べてできることなのか調べてもどうしようもないことなのか、の見当がすばやくつけられるかどうかである
このセンスを鍛えるのに欠かせないのがいわゆる「ググる力」であるのでやってみろと言われるわけなのだ
その最新にある程度追従していかなければならないのは宿命となっている
優秀でなくともある程度マシな人材に育てるにはその感度を鍛えてやる必要がある
ここで重要になるのは「自分から調べる」と言う行為は当たり前であり苦にならないような状態にする必要があると言うこと
もちろん当然であるがググるは比喩であり本当にググるだけでなく書籍や勉強会など必要なものを必要なだけ自分で手に入れる能力である
つらつら思いついたことはこんなところかなあ
