市電保存車両[中日本／愛知県] 名古屋市交通局（名古屋市電）1400形1426号 http://hirolrt.sakura.ne.jp/tokusyu/1426nago/1426nago.html
市電保存車両[中日本／愛知県] 名古屋市交通局（名古屋市電）1400形1426号 http://hirolrt.sakura.ne.jp/tokusyu/1426nago/1426nago.html
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
和風オレキエッテの作り方、これ＞＜(先にイタリア版を食べてないと意味不明だけど)
https://mstdn.nere9.help/@orange_in_space/105248007768491573
キノコっぽいかと言われたらちょっと微妙かもだけど、隠し包丁を入れたカマボコをジムビーム・ライ(ライウィスキー)に漬け込んだやつでクリームパスタ作ったらめちゃくちゃ美味しそうな気がする＞＜
食感もそれほどこだわらなければ、カマボコをさっきの材料で酒蒸し？＞＜；するか、漬け込むのでもよさそう＞＜
物体としてのキノコがダメなだけならば人工トリュフオイルをいれれば一応キノコ風味だけどそういう話じゃなさそうだし＞＜
アワビをスタルカで酒蒸しにしたら、キノコっぽいけどキノコの風味はダメな人でも、キノコのようなフワッとした風味(？)の感じになら無いかな？＞＜
スタルカはたぶん現在入手困難なので、梨ワインと製菓用ブランデーとなにかさらに別のお酒を混ぜたものでもよさそう＞＜
新しい料理を考える基本って、「これだったらあれをいれたらあんな感じになるんじゃね？＞＜」じゃん＞＜
その引き出しが多いほどたぶん頻繁に新しい料理を作れるじゃん？＞＜
代用レシピを聞かれてすぐに「無いです」って答えるの「引き出しちっさ！＞＜；」って思う＞＜
[B! 好き嫌い] 「きのこ嫌いなんですがきのこクリームパスタのきのこの代用はありますか？」に対するリュウジさんがバッサリ回答した話…しかし救いも https://b.hatena.ne.jp/entry/s/togetter.com/li/2344261
無くは無さそうだし、イタリア料理の日本版(チーマディラーパのオレキエッテの和食素材版)とか自作(発明？)してるオレンジ的には「料理研究家なのにそんなものなの？＞＜；」って普通に思う＞＜
1+hogeが出来るかできないかどうかと、静的型付けと動的型付けは関係ないよって説明するためのクラス＞＜
https://gist.github.com/orange-in-space/5142e97f1d045d00469bddcaa1915e65
「静的型付け環境では 1+"hoge" が出来ない！！！」ってお約束な勘違い、
実装して見せる方がそれが勘違いって理解しやすいと思って、1+hogeも出来るしちゃんと静的型検査される『文字も数値も入って加算できる型』を作ってみた＞＜
C# って、特定の型が加算可能かどうかを簡単に完全に判別する方法が無いっぽい？＞＜；
組み込み数値型は、GetMethod()しても加減乗除の関数は実装されてなくて、コンパイラが特殊に処理して加算可能と判別してるっぽいので、組み込み型は全部特別扱いするコードをひたすら書かないといけない・・・・？＞＜；
そういえばこの前
a=3
print(a)
って書ける環境が好きみたいな話が出て、「C# でもあんまり変わらない＞＜」って話になったけど、トップレベルステートメントが有効な状態のC#であれば
var a = 3;
Console.WriteLine(a);
だね＞＜
だったら型推論も併せて導入すればいいというか、そもそも動的型付けのままで型アノテーションを追加するつもりなら、全く関係ないだろそれ＞＜
https://logmi.jp/tech/articles/330373
"...例えばこれから10年後、あるいは15年後、20年後に..." (略) "...ある種の静的型チェックが導入されて、だけど型宣言のない言語が未来で流行るんじゃないかなと私は思っています。
長い目で見ると、その時に今のRubyに型宣言を入れちゃうと、その時の新しい言語の仲間にRubyを入れてもらえないみたいなことが起きるんじゃないかなと思っています。"
まだ読んでないけどもしかしてこれ？＞＜；
「自分の未来予測を信じてちょっと意地を張ってみる」 まつもとゆきひろ氏がRubyに型宣言を入れない理由 - ログミーTech
https://logmi.jp/tech/articles/330373
「動的型付でも安全にできるよ」論が流れてきたがｽﾏﾋｮで反論を書くのもクソダルいので見なかったことにした
オレンジの熊本の妄想公共交通は、熊本電鉄の御代志駅の南から分岐(というか駅移設統廃合)して東に向かうライトレール路線で、県道30号線沿いにセミコンテクノパークエリアに向かい、R325交差点手前から南下し(大津町域は通らず)熊本空港に向かい、さらに数km南にP＆R専用駅を作るって経路＞＜
市電延伸もしたらそこに繋げる＞＜
[B! 地域] ｢TSMCが来た町｣で壮絶な光景を見た https://b.hatena.ne.jp/entry/s/www.gizmodo.jp/2024/04/jasm-fab-kumamoto-kikuyo.html
オレンジが熊本の公共交通システムを妄想してたらちょうど熊本エリアの話題が＞＜；
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
熊本駅前をストリートビューで過去と見比べるとおもしろい＞＜
サイドリザベーション化当初から2019年までは大きな屋根をかぶせた圧迫感がある空間だったんだね＞＜
https://maps.app.goo.gl/79gq2NEYbTKZBuWF7
それが今では大きな屋根を取っ払って明るく緑化された空間になった＞＜
https://maps.app.goo.gl/2ibKfi5ijmdbA2JX9
もちろん、平面的な公共交通である路面電車のメリットを活かしてるので、歩行者空間との一体性があるし、平面交差(踏切)もある＞＜(新設踏切を認めない方針は時代遅れなので撤回すべき！＞＜＃ )
熊本市って、駅前の整備もだけど、サクラマチクマモト周辺も含めて、日本の都市としては珍しく都市空間デザインをちゃんとやろうとがんばってるイメージ＞＜
Engineer-Architects Association/エンジニア・アーキテクト協会 > SERIAL > 02-1｜熊本駅周辺の都市デザイン その１：考え方について https://www.engineer-architect.jp/serial/cate/eawork/1415/
2011.06.01
Engineer-Architects Association/エンジニア・アーキテクト協会 > SERIAL > 02-2｜熊本駅周辺の都市デザイン その２：街路のデザイン https://www.engineer-architect.jp/serial/cate/eawork/1358/
日本が鉄軌道で踏切の新設を出来なくしてしまったのも、公共交通の歩行者空間との一体性を考える前、交通に関してのバリアフリーの発想の前の時代の考え方であって、
公共交通が歩行者空間、つまり道路に近く設置されなければハンディキャップを持つ人々にとってバリアになってしまうという考え方の時代に進んだ今ではまるっきり時代遅れになってしまった＞＜
電車だろうがバスだろうが、歩行者空間に密接させて作れば当然歩行者空間との平面交差が発生する場面もあるからね＞＜
なんで、半世紀ほど前はモノレールやらAPMやらSFレベルなら謎の透明チューブとか、立体的な近未来交通システムが未来の形だったのが、その後ライトレール系やバス系のシステムへの再注目に変わったかというと、歩行者空間との一体性とバリアフリー対応なわけで、
立体的な交通システムは都市自体が立体的であればそういう面でも有利だけど、そうではないのであれば乗降場(駅)の部分を地表まで下げるか、出来なければ上下移動が必要な駅でお茶を濁す事になる＞＜
交通ハブになる中規模な駅であればそれでもいいだろうけど、都市中心部で駅の間隔が短い場面では、乗り物が上下動しまくるか利用者が上下移動だらけになってバリアな構造になるかになってしまう＞＜
もちろん、駅の間隔をあけてしまうと歩行距離が長くなってしまい本末転倒になる＞＜
[B! 起業] なぜ上野案件を取れなかったことを書くか｜すっちー 新交通システム開発中 https://b.hatena.ne.jp/entry/s/note.com/zip_infra/n/n48e907f11bd9
Zippar、おもしろいけど結局はAPMの(とても優れた)ライバルであって、APMが向いてる場面以外ではコスト面はいいだろうけど微妙だよね＞＜
モノレールのライバルでもあるけどモノレールが苦手な面も一緒に出てしまう＞＜
結局の所、立体的な都市以外ではあんまり人に優しくない＞＜
記事の最後に "100億調達してる道路ごと作って自動運転バスで公共交通を実現するベンチャーと日々戦っています。" ってあるけど、そのシステムであれば歩行者空間との一体性が最初からある＞＜
