- 不動産屋さんが言うことを鵜呑みにしない。
- 土地勘があって有益なことを教えてくれることも多いですが、結構いい加減に発言している場合が多いように感じます。鵜呑みにするのはやめておくのが良いです。
- 部屋の広さはメジャーで実測するしか確実な方法がない。
- 壁芯面積というのがあります。例えば、マンションは構造上強度が必要なので壁が厚いです。アパートは相対的に薄いです。 壁芯面積とは壁の真ん中から計算した面積です。そのため、同じ面積表示なのに広さが違うということが当然発生します。 そして、なぜかわからないのですが物件の表示はだいたいこれで行われています。
- 大通りに面している物件は止めておいたほうがいい。
- 日本は相当にクリーンだと思いますが、排ガスに限定せず地面のチリとかそうゆうのが巻き上がっているので衣類や布団を外に乾かすのが躊躇われます。 実際、24時間換気の流入口にティッシュペーパーで簡易フィルターをつけていますが、良い感じに汚れています……。 あと、ロードノイズも中々無視できません。物件によっては二重冊子等で防音が考慮されていることもあるかもしれませんが当たり前ではありません。 1つ入るとグッと良くなるので考慮するといいかもしれません。
- ある程度広いほうが良い。
- 一人暮らしだと寝るところとパソコンがやるところがあれば良いとかになるかもしれません。収納スペースはロフト式ベッドにするとかなり稼ぐことが出来ます。 しかしながら、私の所感としてはある程度広い部屋がある方が掃除がとても楽で生活がしやすいです。 例えば、棚とかを後ろにずらす余裕があると簡単に掃除することが出来ます。しかし、足りない場合は窮屈でなかなか難しいです。メモリーが少ないと大変なのと同じです。
- 宅配ボックスはあると良い。
- そんなに重要じゃないだろうと思っていたのですが、あるとやっぱり良いです。ただし、ボックス付きの住宅にすると物件が限られる他、設置されていたとしても住居数に対して宅配ボックスの数が十分じゃないところが残念ながら多いようです。自分の住宅は幸いあまり使われておらず機能しています。 内覧する際には、宅配ボックスの空き状況をみて埋まり具合を確認しておくといつも埋まってるじゃん!という悲しみは回避できるかもしれません。
- 近くにスーパーがあるのは良い
- 自炊するならば、良いスーパーがあることはかなり重要です。近くでなくとも最寄り駅と自宅の間にあると寄り道で行けるのでGoodです。近年よく見かけるまいばすけっとは、スーパーとコンビニを間の子のような業態で品揃えが中途半端で値段が安くないという欠点があります。営業時間が長くだいたいのものは手に入るので便利ではあるのですが。
- 駅に近いのは良い
- これは慣れもあるのですが。やっぱり近いほうが便利です。が、賃料はだいたい上がります。お金と相談。 場所によってはバスが充実しているかもしれません。例えば、ぎりぎりになりがちな朝だけはバスを使うとか。
- 浴室乾燥機は便利
- 天気に左右されないのは良いです。最近は装備されている物件が多いです。とはいえ、洗濯の手間であるハンガー掛けは必要なのでドラム式とか買っちゃえーという人は関係ないかも知れません。
- 24時間ゴミ出しは便利
- ゴミの事情は自治体でだいぶ違う印象です。回収頻度が高くゴミ捨て場が遠くないのであれば無くてもそんなに気にならないと思います。
2018年10月31日水曜日
一人暮らしの物件選びTips
引っ越しを4回ほどやってみて、思ったことを書き出してみたいと思います。価値観は人それぞれなので役に立つかはよく分からず。
2018年10月6日土曜日
Howto eject usb media like "Safely Remove Drive" from CLI
gio mount --eject /media/nekomatu/$(drive-name)
I use Ubuntu 18.04(Bionic).
Ubuntu is doing mount automatically when USB removal media is connected PC.It's convinient. and un-mount is easy. only one-click eject button from filer. so I want to eject like filer from CLI.
`gio mount --eject /media/nekomatu/45e1dd0a-f7c`
— nekomatu (@nekomatu) 2018年9月21日
やったー!行けましたっ。
What's gio? って感じだったのですが、次のとおりでした。
% gvfs-mount
This tool has been deprecated, use 'gio mount' instead. https://t.co/a3GdLev5zz
2018年10月5日金曜日
歌舞伎座.tech#15「バーチャルキャストを支える技術」 に参加した
歌舞伎座.tech#15「バーチャルキャストを支える技術」
https://kbkz.connpass.com/event/101398/
やっぱりちゃんと、すぐにまとめないと記憶が何もない…(反省)
この記事は12月24日に作成されました。
https://twilog.org/nekomatu/search?word=%23kbkz_tech&ao=a
https://kbkz.connpass.com/event/101398/
やっぱりちゃんと、すぐにまとめないと記憶が何もない…(反省)
この記事は12月24日に作成されました。
https://twilog.org/nekomatu/search?word=%23kbkz_tech&ao=a
2018年10月4日木曜日
OSSの長期利用とメンテナンス に参加した
本ブログは個人のものであり、所属する団体の意見等では一切ございません。
というか、参加自体も仕事じゃなくて個人ですし。私はプラント系の人ではないので推測が多分に含まれています。
間違っていたりしたらこっそり教えてください。いつもにまして脳内ダンプ・ポエム感。
OSSの長期利用とメンテナンス
最初のきっかけは、とある人のCIPに対するツイートを見てうーん、CIPの人がそんな事を考えていないはずがないけどどうなってるんだろー?と気になったからでした。それだったら会場提供するよ的な話になって20人近く参加するイベントになっていました。
ガチ勢の方が多くびっくりしました。
CIPというのはLinuxFoundation配下のプロジェクトで、 Civil Infrastructure Platformのことです。社会インフラ向けのLinux・OSSの利用についてやっていこう的なプロジェクトです。プラント系なのでサポートがミニマム10年とからしいです。
https://www.cip-project.org/
CIPの活動の中でLinuxカーネルのSLTS(SuperLongTermSupport)というのがあるのですが、長期に渡ってバージョンを固定化してFixPatchを当て続けるのはどうなのか?みたいなのが最初の問題提起的なものでした。
Civil Infrastructure Platform Announces First Super Long Term Support Kernel at Embedded Linux Conference Europe
Linux4.4を10年はサポートしていくというブログ
理屈上は十分なテストケースとバリデーションを通せれば、カーネルのバージョンをBump-upしても問題ないのではないかという前提があります。古いカーネルにパッチを当て続けることは容易では無いため、これらの工数やお金をテスト等に回すほうが健全ではないのかという発想です。
これに対しては、やはりバリデーションの難しさ・過去のアセット利用等が背景としてあることが述べられました。
例えば、最終的な受け入れテストなどはプラントに入れてから行ったりします。機能安全については第三者機関に出すことなどもあります。このような体制は比較的昔からあるものだという理解が必要です。こういった時、セキュリティパッチだけを当てて影響範囲はこれだけですというレポートの提出で済むか、テストケースが全部通っているのでバージョンのBump-upしますが通じるかというシチュエーションが容易に想像できます。
過去のアセットとは、ソフトウェア資産を想定した私が最近好んで使うタームです。(ルー大柴みたいな表現になっているのは許してほしいです)
つまり、プラントのような規模が大きいシステムを毎回1から作るのは非合理的ですし、機能安全規格をPASSしたモジュールなどがあれば使いまわしたいと考えるのが一般的です。つまり、枯れたコンポーネントを積極的に使う動機があります。しかしながら、弱点もあって設計そのものがモダンではない、テストが不十分であるといった時代的な課題も抱えていることが想定されます。そうすると、バージョニングの固定が現実的な最適解になルノではないかと思われます。
これはプラントに限らずあるある話なような気がしています。
バージョニングの固定が最適解になりがちというのを過去のアセットという観点で述べてみました。もう一点、これを正当化(Justification)している根拠としてはプラント系はEOLがおおよそ定まっているという要素があるのではないかと私は推測しました。端的に言えば設計寿命であり、一度入れたものをノーメンテナンスで壊れるまで使い続けるということはあまり考えにくいです。ですから、メンテナンスサポートも含めて収益でありビジネスになっているのであれば、バージョニングの固定はシンプルな発想です。
ところで、製品寿命は存外自明ではありません。
皆様は「長期使用製品安全表示制度」というのをご存知でしょうか。最近、扇風機などを買うと「設計上の標準使用期間 : 10年」とか書かれているシールが貼られていたりします。どうゆうことかというと、扇風機とかうっかりすると30年ぐらい使い続けたりします。すると、コードやモーターの劣化に起因して火災が発生したりとか出てきたりしたんですよね。これを防ぐために注意喚起情報を付与することが今では行われています。
他にも「補修用性能部品の保有期間」といって、修理に必要なパーツを何年保持しますと表示しているメーカーもあります。(この辺りは法的なものかは未確認)
さてソフトウェアという観点ではどうでしょうか。スマホはプライバシーの塊とも言えるかと思いますが、ソフトウェアのセキュリティ的な安全性は何時までどのように担保されているか考えている人はどれくらいいるでしょうか。
IoTマルウェアのMiraiや監視カメラの初期パスワードアタックなどはかなり有名ですが、どこまでどのようにサポートされるべきなのでしょうか。
ソフトウェアも製品に組み込まれている部品の1つですが、これがクリアリーになっているケースはそこまで多くありません。
スマホの例だと、Googleが出しているブランドのNexus・Pixcelシリーズはセキュリティアップデートの日付を明示しています。一方で、これを認知しているユーザーの割合や、サポート期間を超えて使い続けた場合についてはまだまだ社会的なコンセンサスや認識が無い状況だと認識しています。
主にWeb系でマイクロサービスアーキテクチャという話がありますが、これは組込みとかにも言えるんじゃないかなーと思っています。
コンポーネントを疎結合にというのもあるのですが、もう少しトータルデザインとして。APIやインターフェースを界面として個々の品質や実装については担保されていて入れ換えの自由が効くように。
コンピューターテクノロジーの進化はどの産業よりも変化が早く急速に社会を変化させていきました。ここに、コネクティビティ(ネットワーク)が加わったことにより物理的な制約条件をしばしば突破する強烈なインパクトをもたらしています。現代のソフトウェアは一人では見きれないほどの複雑で非常に高度なものになっていて、しばしばセキュリティ的な問題が含まれ時に狙われるという状況になっています。
高度なソフトウェアを新規でほいほい書けるかというとまだ世の中はそうはなっていないようです。そのために、過去のアセットを使わざる得ない状況があります。ベンチャー企業とか新規参入者はこの辺りが付け入る隙になっていると思います。逆の観点から言うと新規参入障壁とかそういった言葉が出てくる気がしています。
Amazonは元々本の流通をやっていたわけですが、電子書籍を始めちゃうように自分自身で破壊的なイノベーションをしていけるのは相当強いし、やっていかなければいずれか新規参入勢にやられちゃったりするんじゃないかなーと思っています。
終わり。
というか、参加自体も仕事じゃなくて個人ですし。私はプラント系の人ではないので推測が多分に含まれています。
間違っていたりしたらこっそり教えてください。いつもにまして脳内ダンプ・ポエム感。
OSSの長期利用とメンテナンス
昨日はCIPは元の意味で塩漬けを作ろうとしていることを十分に理解することができた。
— nekomatu (@nekomatu) 2018年10月5日
CIPの通りすがりの人が、こっちの塩漬けと良くない意味での塩漬けの意味が違うと言っていた意味が今ならわかる。https://t.co/8xvfbzQMLp
塩漬けってそもそも腐敗を防ぐ知恵でしたよねみたいな。
— nekomatu (@nekomatu) 2018年10月5日
最初のきっかけは、とある人のCIPに対するツイートを見てうーん、CIPの人がそんな事を考えていないはずがないけどどうなってるんだろー?と気になったからでした。それだったら会場提供するよ的な話になって20人近く参加するイベントになっていました。
ガチ勢の方が多くびっくりしました。
CIPというのはLinuxFoundation配下のプロジェクトで、 Civil Infrastructure Platformのことです。社会インフラ向けのLinux・OSSの利用についてやっていこう的なプロジェクトです。プラント系なのでサポートがミニマム10年とからしいです。
https://www.cip-project.org/
CIPの活動の中でLinuxカーネルのSLTS(SuperLongTermSupport)というのがあるのですが、長期に渡ってバージョンを固定化してFixPatchを当て続けるのはどうなのか?みたいなのが最初の問題提起的なものでした。
Civil Infrastructure Platform Announces First Super Long Term Support Kernel at Embedded Linux Conference Europe
Linux4.4を10年はサポートしていくというブログ
理屈上は十分なテストケースとバリデーションを通せれば、カーネルのバージョンをBump-upしても問題ないのではないかという前提があります。古いカーネルにパッチを当て続けることは容易では無いため、これらの工数やお金をテスト等に回すほうが健全ではないのかという発想です。
これに対しては、やはりバリデーションの難しさ・過去のアセット利用等が背景としてあることが述べられました。
例えば、最終的な受け入れテストなどはプラントに入れてから行ったりします。機能安全については第三者機関に出すことなどもあります。このような体制は比較的昔からあるものだという理解が必要です。こういった時、セキュリティパッチだけを当てて影響範囲はこれだけですというレポートの提出で済むか、テストケースが全部通っているのでバージョンのBump-upしますが通じるかというシチュエーションが容易に想像できます。
過去のアセットとは、ソフトウェア資産を想定した私が最近好んで使うタームです。(ルー大柴みたいな表現になっているのは許してほしいです)
つまり、プラントのような規模が大きいシステムを毎回1から作るのは非合理的ですし、機能安全規格をPASSしたモジュールなどがあれば使いまわしたいと考えるのが一般的です。つまり、枯れたコンポーネントを積極的に使う動機があります。しかしながら、弱点もあって設計そのものがモダンではない、テストが不十分であるといった時代的な課題も抱えていることが想定されます。そうすると、バージョニングの固定が現実的な最適解になルノではないかと思われます。
これはプラントに限らずあるある話なような気がしています。
バージョニングの固定が最適解になりがちというのを過去のアセットという観点で述べてみました。もう一点、これを正当化(Justification)している根拠としてはプラント系はEOLがおおよそ定まっているという要素があるのではないかと私は推測しました。端的に言えば設計寿命であり、一度入れたものをノーメンテナンスで壊れるまで使い続けるということはあまり考えにくいです。ですから、メンテナンスサポートも含めて収益でありビジネスになっているのであれば、バージョニングの固定はシンプルな発想です。
ところで、製品寿命は存外自明ではありません。
皆様は「長期使用製品安全表示制度」というのをご存知でしょうか。最近、扇風機などを買うと「設計上の標準使用期間 : 10年」とか書かれているシールが貼られていたりします。どうゆうことかというと、扇風機とかうっかりすると30年ぐらい使い続けたりします。すると、コードやモーターの劣化に起因して火災が発生したりとか出てきたりしたんですよね。これを防ぐために注意喚起情報を付与することが今では行われています。
他にも「補修用性能部品の保有期間」といって、修理に必要なパーツを何年保持しますと表示しているメーカーもあります。(この辺りは法的なものかは未確認)
さてソフトウェアという観点ではどうでしょうか。スマホはプライバシーの塊とも言えるかと思いますが、ソフトウェアのセキュリティ的な安全性は何時までどのように担保されているか考えている人はどれくらいいるでしょうか。
IoTマルウェアのMiraiや監視カメラの初期パスワードアタックなどはかなり有名ですが、どこまでどのようにサポートされるべきなのでしょうか。
ソフトウェアも製品に組み込まれている部品の1つですが、これがクリアリーになっているケースはそこまで多くありません。
スマホの例だと、Googleが出しているブランドのNexus・Pixcelシリーズはセキュリティアップデートの日付を明示しています。一方で、これを認知しているユーザーの割合や、サポート期間を超えて使い続けた場合についてはまだまだ社会的なコンセンサスや認識が無い状況だと認識しています。
目指していきたい方向性
ここから脳内ダンプ。ポエムがさらに深刻になってきます…。とほほ。主にWeb系でマイクロサービスアーキテクチャという話がありますが、これは組込みとかにも言えるんじゃないかなーと思っています。
コンポーネントを疎結合にというのもあるのですが、もう少しトータルデザインとして。APIやインターフェースを界面として個々の品質や実装については担保されていて入れ換えの自由が効くように。
転換期のつらみ
私の考え方としては、今は転換期のつらみと捉えています。コンピューターテクノロジーの進化はどの産業よりも変化が早く急速に社会を変化させていきました。ここに、コネクティビティ(ネットワーク)が加わったことにより物理的な制約条件をしばしば突破する強烈なインパクトをもたらしています。現代のソフトウェアは一人では見きれないほどの複雑で非常に高度なものになっていて、しばしばセキュリティ的な問題が含まれ時に狙われるという状況になっています。
高度なソフトウェアを新規でほいほい書けるかというとまだ世の中はそうはなっていないようです。そのために、過去のアセットを使わざる得ない状況があります。ベンチャー企業とか新規参入者はこの辺りが付け入る隙になっていると思います。逆の観点から言うと新規参入障壁とかそういった言葉が出てくる気がしています。
Amazonは元々本の流通をやっていたわけですが、電子書籍を始めちゃうように自分自身で破壊的なイノベーションをしていけるのは相当強いし、やっていかなければいずれか新規参入勢にやられちゃったりするんじゃないかなーと思っています。
終わり。
2018年10月1日月曜日
Yahoo!ジオシティーズ、お世話になりました。
ジオシティーズ、懐かしすぎて……。ありがとう、ジオシティーズ。
— nekomatu (@nekomatu) 2018年10月1日
お世話になりました!YahooBBモデムが駅前で配られている時に我が家も契約して、パソコンも買って。WEPのわけわからんパスコードを必死こいて設定したりWindowsXPな端末にPCカード指したり。そんなことをやる前から市の児童館に設置されてる貸出のPCからジオシティーズにアクセスしてページ作ったり。 pic.twitter.com/MzvdkarpWz
— nekomatu (@nekomatu) 2018年10月1日
このサービスはわりかし原点かもしれません。年齢がバレる。
ここからHTMLを学びパーミッションや文字化けの洗練を受けたのです。
当時のアップローダはなぜか全部EUCに変換しちゃうとかだったような。もう何も覚えていません。
FFFTPでバイナリモード?アスキーモード?よくわかんないけど、手元のメモ帳で書いたHTMLをアップロードしてはWebブラウザを更新したのです。
ちょっと動いてすごいなってなって、とほほのWWW入門のコードをベースにできることを増やしていったような記憶があります。
当時はフレーム(iframe)とか結構当たり前で、上手に設定してないとどんどん左のメニューが入れ子になっちゃうとか合ったような気がします。
レスポンシブデザインとかなくて、決め打ちなのでレイアウトとかどうなってたんでしょうか。それでも、手元でいい感じに分割されるのが楽しかったです。
わけもわからずキラキラするJavaScriptをコピペしてキャッキャしてたのも懐かしいです。
そこからCGIなるものをがあるとしって、Infoseekに行ってみたり、カウンターなるものを設置してみたり。
そういえば、一緒に初めた友人のページばっかりカウンター回ってジェラシー感じたりもしましたっけ。
小学生だった自分の家にはまだパソコンとかインターネットはなくて、児童館で貸し出してくれるWindows95seとかを触ってたような気がします。
申請書を書けば誰でも使えるのですが、使っているのは自分たちぐらいでした。
そういえば、PCがガリガリガリとHDDの音を立てて起動するのに5分ぐらい待つ。というのも遠い昔の話ですね…。
当時もWebチャットとかお絵かきチャットとかBBSとかFlashとか合ったような気がします。Yahooキッズが懐かしいです。
そういったコミュニケーション系には自分は特にはまらずこの辺りには思い出がないです。
ニフティサーブとかパソコン通信とかは分かりません。
でも、この世界においてはおじさんに一歩足をかけてるんだなとやっぱり実感するのです。
登録:
投稿 (Atom)