オレンジは、「なりたい」よりも「やりたい」いろいろな事ができるかもって意味で書いてたからわりと違ってた><
https://twilog.org/orange_in_space/date-170514
オレンジは、「なりたい」よりも「やりたい」いろいろな事ができるかもって意味で書いてたからわりと違ってた><
https://twilog.org/orange_in_space/date-170514
このアカウントは、notestockで公開設定になっていません。
分解したりはしなかったけど、いつもと違って巻き込まれたままなかなか抜け出せなくて危なかったかも><;
elite:dangerousで、なんか中性子星での燃料補給の場所来たら、見た事無いレベルに噴出してる量が激しいんだけど、これっていつも通りつっこんでもだいじょうぶなんだろうか?><;
@babukaru Intel は x86 以外も色々やろうとしてるけど FPGA にしろ Xeon-Phi のような打倒 GPGPU みたいなやつにしろいつも失敗してるし Intel NUC や Edison ボードもあんまり成功した感じしないから x86 以外だいたい失敗してる気がする
DEC Alpha に携わり AMD Athlon や AMD Sempron を作り AMD Opteron や AMD Athlon64 を支援したり x86-64 の命令セットの共著になったり AMD の黄金時代を支えたと思ったら iPhone の ARM プロセッサの A4 や A5 を作ってまた AMD に戻って Ryzen つくって作り終えたら Tesla で副社長やったと思ったら Intel に行く Jim Keller,強すぎて人類か疑う
このアカウントは、notestockで公開設定になっていません。
@nkdr かなりカビ味の癖が強い事は強いから、先に他のブルーチーズ(羊とかのはさらに強烈だから普通に牛の)を食べてみてからの方がいいかもしれない・・・><(いきなりだと、もしかしたらカビ味が強烈すぎてブルーチーズ自体嫌いになっちゃう可能性が><;)
@nkdr 一番好きなチーズ>< かなりクセがある味だけどカビの近く(周り?><)がなんか旨み成分っぽい味がしてすごくおいしいかも>< カビっぽい味がだいじょうぶな人なら間違いなくおすすめかも><
オレンジはいまは問題なく繋がるけど、読売オンラインってたまになぜかものすごく表示遅くなる事があるのすごく謎><
普通にボール当たって死ぬんだよなぁ。
2007年9月1日大阪:PL学園心臓震盪死亡事故|心臓震盪|事故事例・ニュース|すまいる舎こども救命講習センター
http://www.smilesha-childcare.net/news/commotio-cordis/2007/09/01/181/
モバイルバッテリーな感じノッテクルマつみっぱ運用でもファイヤしたりしないの・・・?><(なんか夏の長時間駐車時とかやばそうなイメージあるけど><(イメージ))
Mercurial使ってみようかな><と思ってちょっとググって色々読んでて思ったけど、オレンジがバージョン管理システムに必要としてるものって、複数の履歴の統合なのかも?><(その日のちょこまか弄った膨大になっちゃった履歴を、実際のひとまとめの変更の単位に統合するみたいなの><(それなら気軽にちょこまか履歴ができても問題ない><))
個人プロジェクトだと、これでいいだろうと思った時点でコミットして、やっぱり問題を見つけて調整してまたコミットみたいなことはする。gitだと履歴いじってコミットをまとめたりするだろうけど、Mercurialだと、もうそのままありのままに記録している。
ちょこまかビルドして実行して?><ってなってなおしてみたいな、ちょこまかする場合(?)、どうバージョン管理すべきかわからないかも><
フォルダまるごとバックアップというかスナップショット方式?でバージョン管理してる><(管理出来てない)
まず、唯一オレンジでもgitを使えないと困る場面としてgithubが>< 正しくないデザインの物はなるべく使わないというポリシーがあるので、正しくないデザインと考えるgithubは使いたくない><
となると、それ以外で使うという事になる><
極端に言うと一人でもバージョン管理システムは必要か?><という話になる>< オレンジは必要と考える><
であるのにも関わらずオレンジにとって現時点でgitがなぜ不要なのか?><という事になる><
それはバージョン管理システムというものはバージョン管理できる人が管理するためのものであって、極端に管理出来ない人が使っても謎の履歴で溢れかえるだけになると考えているから><;
つまり、オレンジにとって先にすべき事は、バージョン管理の正しい考え方ができるようになることであって、それはバージョン管理システム固有のノウハウを得るより先にすべき事と考えているから><
ものすごく恥ずかしいけどオレンジはgit使えない><
(ある意味でオレンジにとっては必要性が無いとも言える><(この説明はとても長くなる><;))
ていうか、その時点で対策すべき事象(=旅客への案内上必要な情報)としては、単に人身事故であって、自殺であろうが極端に言うと突き落とし殺人事件であろうが、それを検証等をするのは別レイヤの話であって、あくまでその時点で対策すべき事象(=旅客への案内上必要な情報)としては、単に人身事故かも><(冗長な文章><;)
このアカウントは、notestockで公開設定になっていません。
この前の「プログラミングができるとは><」の話の時も、最初にisanaさんのツイートの引用してたら逆に簡潔で済んだのかも><;
オレンジが説明下手すぎるパターンで、その部分は当たり前だよね><とかよく知られてるよね><って思いこんでて、オレンジの標準的には短く書いた部分が、「それちがくない?」ってなって、その部分説明するのに数時間かかる現象、どうしたらいいのかわからない><
(結果的にそういう部分も根拠込みで全部説明した時の方が一回で済んで短いことがわりと・・・><)
オレンジが開発中で一部公開してる感じの音解析アプリのスペアナ部分、まだ試作品なので、"書き方はどう見ても手続き型"で、245行のひとつの巨大メソッドとして書かれてます><;(本番コードじゃなくデザインの検討用のモックアップ(?><;)だからだけど><;)
手続き型からオブジェクト指向型に強引に移植されて、書き方はどう見ても手続き型で、1万行を超えるゴッドクラスや1000行を超えるモンスターメソッドなどを見たら自然と口から出ますよ。>BT
このアカウントは、notestockで公開設定になっていません。
(ていうかオレンジ的には「それはそうだよね」になって「でも、某ボブ氏は・・・><;」「うん(汗」みたいな会話を想定してた・・・><)
ノーマンかニールセンが書いたものを引用すると意味が強く伝わるパターン・・・?><;
(これ><;
https://mstdn.nere9.help/@orange_in_space/100000112255200864
https://mstdn.nere9.help/@orange_in_space/100000117427431230
(x度も oでも))
基本的に手っ取り早さ的にはそうかも><;
一方で、わかんなかった側もどうしてわかんなかったのかわかんないくらいのある意味小さな問題って、だからこそ自分でも発見しづらくてその時に検証しないとわかんなかったりする・・・と言う意味では貴重ではあるかも><
それは間違いなくそうなんですが、その「ここがわからなかった」をはっきり説明できる人と説明できない人とで、どちらが問題解決が迅速かつ効率的かといえば、おそらく前者なので
本の予算の都合でオレンジはまだ読んでない本だけど、よく名前を聞く本で言うと、
O'Reilly Japan - リーダブルコード https://www.oreilly.co.jp/books/9784873115658/
みたいな感じでちゃんと書けているか?><を検証するのに、自分だけで考えるよりも、「あなたが書いたもの作ったものでここがわけわからなかったです・・・」って人をサポートすると、より手っ取り速いですよって言いたい・・・><
そうじゃなく自分のコードを読んだ人が🤔ってなってるのをサポートするとどうマズく書いたのかに気づけるよ的な事が言いたい・・・><
クソコードを読んだところで書かないように改善されるかというとうーんですよ
まあ命名がロクでもないものも沢山見たことがあるけど、「ロクでもないと思うならパッチを投げてみろ」とかそういう世界だよなぁという感想しかないので、あくまでユーザはオマケでしかなくて(←言葉が悪い)、対等に意見を言いたいならあなたも開発者ステージに来てください、という気持ち
そういうことじゃなく、書く側のスキルが上がるよみたいな事が言いたい・・・><
(言い方を変えると、読めないような酷いコードを書かないようになるスキル(の一部)かもみたいな><)
結局この「自分でやれよ」を連結させて自分を最優先で世界を良くしていこうというのも OSS のひとつの姿だと思うので(そうでないプロジェクトが多いのもわかっているし、特に大規模なものは社会的な意義を重視しているように思うけど、それはそれ)
まあ不満なら「オレが使いづらいから使いやすくしてやったぜ感謝しろよ」みたいなパッチを投げてもらえれば、私がそれを良くないと判断しない限りにおいて受け入れますし(ただしそれは私が負いたいコストではないのであなたが実装してね、という)
結局、他人のプロジェクトを良くするのも自分のプロジェクトを書くのも、大抵は自分のためなんですよね。他人に公開するのは“おこぼれ”で世界が豊かになればいいと思っているからなので、他人に使ってもらうことは重要な目的とは捉えていない
ライブラリとかでも命名とかがマズければ、コードを端から端まで読まないとわからないようなものになっちゃうかも><
そもそもアプリケーションじゃなくてライブラリばかり作って/使ってきたので、「API を見てわからないのであれば、理解度が不足しているだけでは」という見捨てる系思考が強い
正直見付からなければ issue を立ててくれれば使い方は示せるし、それでわからなければそちらの勉強不足ではというお気持ちなので、なんと言えばいいか、「発見と提示はこちらで肩代わりできるが、理解はそちらの仕事」というお気持ち
たぶんそういうのの極々初歩的な最低限のUXデザインって、pログらミングの知識とは別に、でもプログラミングするための知識として学ぶ必要があるのかもしれない><(何も書いてないボタンを配置しちゃう人も実際に居た><;(何も書いてないボタンで何が起こるかわかるわけないじゃん!><;って思うけど、そう思い至らない人もいるっぽい><(というか実際に居た><;)))
自分が作ったものの場合は、どうデザインがまずいのか?>< 自分だけわかってて全然説明になって無くて自分以外誰もわからなくなってるような点はどこか?>< とかを見つけられるかも><
自分が作ったものについていえば、代わりに調べるもなにも自分が全部知ってますからねぇ。
でも確かに知的探求としての面白さは結構重要な気がする
オレンジがいわゆるエスパーなサポートっぽい事するの好きなのも、学べる事がすごく多いから><
わからない人がどうわからなくなるのかって学べるし、代わりに調べれば知識を多くつけられるし><
サポートするのって、困った人本人がどうのよりも、サポートする事によって色々学べるメリットの方を重視して考えると、サポートする側の特になるかも><
ていうか何らかのアプリ作って配る時に、「readme書くのめんどくさいから、とりあえずわかんない部分聞いて><;」って思う事無いかも?><
わかんない所を聞いてもらえると、どこで詰まるのかわかるからそれでreadmeを書くのが楽になるみたいなの><
一応初心者の特にわけがわからない人の相手って、デザインをどうするか?><を学ぶと言うか検証するにはすごく有用かも><
逆に言うとそういう風にも役に立たない程のであれば(つまり・・・><;)、仮にすごく暇でもスルーしてもいいのかも?><;
まあソフトウェアの界隈について言えば、開発者とユーザだけでなく中間段階がいろいろあるので(たとえば一発コントリビュータだったりコミュニティだったりいろいろ)、その辺りがうまくなんとかやっていくのが活路なのやもしれぬ
私は一定ライン以下であれば「他で勉強して出直してくれ」と切り捨ててしまうお気持ちなんだけど、そうやって初心者に不親切だと文化が廃れるという人もいますよね
これ割と深刻な問題だと思っていて、開発者のリソースが初心者/無知な人に割かれるのをどこまで許容するかみたいなの、人によって意見が割れるし難しい
なにわろてんねん、ボブがgitにサインインするのにMastodonアカウントがいるのかとか意味不明なこと言ってたぞ
このアカウントは、notestockで公開設定になっていません。
.................
c................
C...............
c..............
C.............
c............
C...........
c..........
C.........
c........
なにだったか忘れたけど、すごく昔にLinux上で見たと思うんだけど、コマンドラインでなんかのプログレス表示が . を C と c で表したパックマンっぽいものが食べるみたいな表示見た記憶があるけど、あれなんだったんだろう?><
このアカウントは、notestockで公開設定になっていません。
血液型占いには科学的根拠がないし、そんな少ない分類で分けられるわけないし、基本的にバーナム効果で・・・って話とは別に、極端に偶然にもそれにぴったりとても深く当てはまってしまう人(><)も居るし、浅く当てはまる人も居るかも実際の血液型とは無関係に><