  |
はてなキーワード: スタンドアローンとは
PSVRでやっと評判のいいVRゲームアストロボットが出たと思いきや、売り上げ5000本で打ち止め
俺はもう４か月は触ってないけど、みんな使ってる？何に使ってる？
VRChat界隈は「VRChatはこんなに先進的なんです！」「VRChatで作られていないものはない！」みたいなアピール頑張ってるけど
傍から見たら身内で盛り上がってるだけな印象
てか、どんだけ頑張っても利益でるわけでもなく
コストパフォーマンス考えたら、2Dの紙芝居で十分だったという
わずかな期間で大量発生での食い合いが激化して、全体的にピークを過ぎて落ちてきて、来年はもう伸びることはなさそうだ
xRとか去年ぐらいから言いだしたけど
VR、AR、MR、SR全部合わせても話題のアプリはほとんど登場しないという
一番話題になったのはiOS12で使えるようになったARメジャーかな？
BtoCは全然ダメだけどBtoBは好調だよ、というのもどこまで本当なんだか
VRM？ これ付加情報がちょっと足されただけの単なる3Dのファイルフォーマットで、VRとはあんま直接関係ないよね
プログラミングは道具というのは事実。ネジや木や鉄やそれを組み立てる道具みたいなもので目標が無いと上達するのは難しい。気づいてないかもしれないけど学校の教科書は何百年という単位で頭の良い大人が作り出した教育方法で、プログラミングを自習する場合は自分で目標を作らないといけない。例えば理想の目標があったとして、それを１００とすると天才でもない限り簡単には作れない。しかし１０の別の目標を達成して次に２０の目標と順に達成すれば５０くらいの時には１００までの距離が分かり、その目標に突き進むか、諦めるか、別の目標を目指すかがはっきり分かるようになる。ひとまず簡単に出来るものを５個作るといいよ。
次にプログラミング言語とその環境の探し方を知らなければいけない。良くないものを選ぶといきなり挫折する。環境設定の話が出ているのでたぶん問題ないと思う。ただ個人的な感想では言語を探している時点で疲れて投げ出してしまうという事が多かった。重要なポイントとしては
１ゲームが作れるから最低でも２Dのグラフィックが描ける言語、３Dか物理演算があるとさらによい。
２ヘルプの付いた統合開発環境が良い。でも、これだと選択枠が限られる。
３日本語が使える言語だと幅が広がる。表面的には日本語が使えても、言語内部では違うために変換に苦労する。
４誰も使わなくてもアウトプットが出来る環境だとモチベーションが上がる。
５プログラミングの中核は同じなので言語を変えても無駄になるものは無い。
６プログラミングにはまっても一日３０分は最低でも運動する。学校や買い物の行き来でも問題ない。
ちょっと癖が有るけどHSPとかかな、RubyはWindowsでスタンドアローン動くしWebでも動く、スマートフォンに興味あるならiOSかAndroidの開発環境もありかもiOSは知らないけど、Androidの方はクレジットが無くてもデビットカードが有ればアプリを登録できたはず。プロバイダの無料のホームページ枠があると思うけど、無いならレンタルサーバーを月100円のでいいので借りてみて、簡単なホームページを立ち上げて見るのをおススメする。
https://anond.hatelabo.jp/20180920011754
上の記事みて日頃思ってたことがあったから書く。（主語でかめだけど気にすんな）
記事の言う通り、ネットの発達で上の階層の世界にはアクセスしやすくなったけど、
それは同時に自分が今いる階層（上よりもつまらない）を客観視せざるをえない状況にされてるってことを俺は唱えたい。
ネットに繋がれば、自分よりもルックスもお金も社会的地位も遥かに上の人間が星の数ほどいて、
とあるアニメのキャラクターが幼い頃の球場に行って初めて数万の観客を目の当たりにした時に、
ずっと特別だと思った自分もちっぽけな存在のひとりだってことに気づいて、
ひと昔前ならいい車に乗って、高級な時計を身につけてりゃ優越感に浸れてたんだろうけど、
20代でランボルギーニに乗ってる上の連中の日常にyoutubeやインスタを通じてアクセスできるこのご時世で、
そんなに背伸びして地元で見栄を張ってもどうなのってなるわな。
だから、今の若者の〇〇離れがうんぬんって話に的はずれなのが多いのは、
おっさん連中がそのへんのことを体感的に理解できてないんだろうなぁと思ってる。
もの買うだけで自尊心やステータスを保てるほど簡単な世の中じゃないんだわもう。
若い連中は無欲ってよく言われるけど、逆だよ逆。
モノじゃ満足できない水準まで欲求高まってんのよ。
上の階層の連中の存在が身近にある限り、買ってみたじゃしょぼすぎて満足できないのよ。
やってみたじゃないと。
だからナイトプールやハロウィンに行っちゃったり、時には海を渡ってセブ島とかに行って何者かになろうとするわけ。
映えれるモノより映えれる経験のほうが大事。金持ってるだけじゃ真似できなしな。
まあそうやって頑張って人と違う経験をしようとするんだけど、
やっぱり前者はウェイ系だったり、後者は意識高い系として、またそういう連中はカテゴライズされて特別でもなんでもなくなる運命なんだけどな。
サマータイム関連でマウント取りたいプログラマーがブコメやブログ書いてるけど
もしかしてこんなびっくり低レベルプログラマーが世の中のいろんなプログラミングしてるの？
サマータイムよりそっちの方が怖い。
プログラムで時刻を扱う場合はほぼほぼ１００％ライブラリの機能を使う。
日付なり時刻を表すオブジェクトを作る。
そうしないと単純な引き算とか足し算が面倒だろ？
今から10日後ってどうやって計算する？一ヶ月は必ず30日じゃないんだぞ？
だからライブラリに任せる。そこそこのプログラマーなら面倒なことをいちいち実装しない。
で、そういう実装をすると内部で保存されてる時間情報と表示する情報は別物になる。
たいていは内部ではUTCで保存されていて、そいつを表示の時にJSTにする。
OSなりのロケール情報から何で表示するべきなのかを取って来てそれに合わせて表示させる。
サマータイム対応をする場合はこのロケール情報を変えるのであって、内部の時計は変更しない。
だからほとんど全ての時間的演算は影響を受けないし、コードを変える必要もない。
だから正確に言うとサマータイムが導入されても「時計は変更しない」
表示を変えるだけだ。内部時計と表示の関係をわかってない人が多すぎる。
はてなの（おそらくエアプ）プログラマーがその辺をわからずに記事にしてるのがほんとキモい。
で、そんじゃ影響はないか、っていうとそうじゃない。
さっきの10日後、みたいな演算は影響を受ける。２時間ずれる。
あと、簡単なところだとcronなんかのスケジューラは影響を受ける。
夜中の1時に実行するっていうcronの設定はロケールに応じて意味が変わるので、切り替えの時に1日に２回実行されたりするかもしれない。
ただ、利用者側に見えないところのスケジュール実行なら、ぶっちゃけサマータイム対応させる必要はないと思ってる。
サマータイムなんて所詮は人間が見たときの時間であって、内部の時計の話ではないからだ。
エクセルがタイムゾーンに対応していないとかの話もあるが、スタンドアローンで動いてるなら全く問題ない。
影響は皆無ではないしかなり大きいと思うが、OSの更新とかそんな大それた話ではないはずだ。（もちろん、将来的に変更する必要はある）
じゃぁサマータイム賛成なのか？って言われるとそれは別だ。
おそらくスケジューラの影響だけでも相当大変だし、それに関連したシステムの再検証とかどう考えても時間が間に合わない。
内部のコードがどうなってるかわからないから時間に関係してる・していないに関わらずシステムは全て再検証だろう。
どう考えても無理なのは無理だが、根本的に無理かと言われたらそうでもないはずなんだ。
もしかしてハードコードでJSTって書いてたり、独自の時間管理ライブラリを使ったりしてる人って結構いるのか？
String time = "2018-08-16 13:41:00"
とかやってんの？
スタンドアローンならそれでもいい（勝手に電源落として時計あわせりゃいい）が、そうじゃないシステムでそんなアホなことしてる人って多いの？
デスクトップはWindows自作PCで最新の高性能CPUとGPU、大容量高速なストレージとワークメモリを搭載。WSLのUbuntuによってPOSIX環境を構築。
デスクトップの周辺機器は英語配列ゲーミング系、もしくは静電容量方式の英語配列キーボード。好みによってはトラックボール、作業用にゲーミング左手キーボード、フットスイッチ。ディスプレイは4Kで複数枚。音声の入出力はオーディオインターフェイス経由。
ラップトップはMac。使用するアプリは可能な限りクロスプラットフォームとして提供されているものを使用。処理性能の低さはeGPUで補完。
テキストエディタはVim、WebブラウザはChrome、オフィススイートはGoogle Documents、チャットはSlackとDiscord。
ルータは高速なゲーミング系、もしくはGoogle Wi-Fiをメッシュ運用、YAMAHAも良いけど手軽さには敵わない。
スマートフォンはiPhone Xを裸運用。動画撮影時にZHIYUNのジンバルを使用。気分で超広角やNDフィルタ系のスマホレンズを使う。
タブレットはiPad Pro、Smart Keyboard装備、手書き系はApple Pencil。
スマートデバイスの周辺機器はAnker。オーディオ関連はAirPodsかBeats。
iTunesはゴミ。そのためAndroidを頻繁に検討してしまう。ただやっぱりAndroidはイヤ。
スマートウォッチは他に選択肢が無くてApple Watch。PebbleがFitbitに買収され絶望している。
電子決済は交通系かApplePay、ApplePayの中身はiD。
電子書籍はAmazon Kindle、音楽はSpotifyとApple Music、動画はYoutubeとNetflix、通販はAmazon、食材はネットスーパー、服はZOZOTOWNおまかせ定期便。
SNSはTwitter、ログイン頻度が非常に落ちてるがFacebook、次の楽園としてMastodonに注目。視覚デザインアイディアのプールとしてPinterestは優秀。
ブログは静的サイトジェネレータを使って構築。プラットフォームはGithub PagesやAWS。WordPressは古い。
VLOGを嗜み、普段使いの動画カメラはiPhone XやGoPro、SONY RX100。本気を出すときデジイチとZHIYUNのジンバルを持ち出す。
空撮ドローンはDJIの中型ドローンかRyzeTech Tello。
スマートスピーカーはGoogle HomeとGoogle Home Mini、HomePodは現状で選択肢に入らずHomePod買うならGoogle HomeMaxを買う。
Amazon Echo派も居る。Amazon Echo Spotを実家に置こうか検討してる。
ホームIoTとして連携しやすいのでテレビはSONYの4Kテレビ、電灯はPhilips Hue、赤外線制御はNature Remo。掃除機はDysonやiRobot Roomba、マキタのコードレスクリーナー。
調理関係は電子調理で電子レンジオーブントースターやホットクック、ヌードルメーカー、Vitamixなどで省力時短調理をする。食器洗いは食洗機。
洗濯は洗濯からの乾燥コースで基本畳まない。シャツのアイロンがけはアイロンいら〜ずとハンドスチーマー。
Raspberry PiでホームIoTサーバを構築し、既製品では提供されていないサービスを自作しIFTTTやSlackとも連携、リモートコントロール。ChatBotもついでにラズパイで。OSはUbuntu Server。
TVでの動画視聴はAppleTVかChromecastやテレビ内蔵AndroidTV。Amazon FireTV派も居る。これまでのメディア資産はDLNA経由で視聴。
ゲームハードはSIE PlayStation4とNintendo Switch。XBox系はWindowsでプレイしたら良いと思ってる。
スタンドアローンVRゴーグルのOculus GOで動画見たりVRChatもする。
棚はディアウォールやラブリコでDIY。一家に一台マキタのバッテリー式インパクトレンチ。
文房具はツバメノートに本革カバーか高橋手帳に本革カバー、ボールペンにJETSTREAM PRIMEかサラサグランド、万年筆はコクーンやバランスやサファリ、ハサミはフィットカットカーブツイッギー。
バッグやバックパックはカメラ向け、ブランドはPeekDesignやSUPER CONSUMER。
軽い運動にはロードバイクを使用し、そんなにガチガチなカスタムはしない。車は所有していないかスポーティなデザインのものかハイブリッド。
----------
追記(2018/07/04/13:14)
クリエイティブ関係でフォトレタッチは安定のPhotoshopでOSS派の人はGIMP、動画編集はAdobe PremiereでDavinci Resolveが伸びてきている。DTMはGarageBandで、当然DTM趣味の人は本格的なLogicやCubaseを使ってる。
絵描きが周囲に1人しか居ないので聞いてきた。参考にならないかも知れないが「Photoshop、Illustrator、Clip Studio Paintがメイン。最近Paintstorm Studioが面白い」と言ってる。
----------
ネットの情報と某大手IT企業勤めの俺の周囲の様子から平均としてまとめてみた。
思い出しながら書いたのでアッチコッチにジャンルが飛んで申し訳ない。
平均なので、もちろん自転車趣味のやつはガチガチにカスタムするし、カメラ趣味のやつはレンズを買いまくってる。
この問題に関して「xxという観点から問題はないです」という無罪派のエントリーはたくさん見かけるし、自分もそれにほぼ同意してるんだけど、それらエントリーにブコメで「いやダメでしょ。なんで合法なのかなぁ」的なことを書いてる人もそこそこ見かけているわけで、でも彼らが少ない文字数のブコメ内で論拠をちゃんと示してくれていることはほぼ無く、自分としてはどこに違法性があるのかを本気でわからずにいる。一例をあげると、
この件については憤ってる技術者が何に憤ってるのかほぼ理解できない。日本人技術者なら変なことはしないだろうと信頼してたが、実際のレベルはバックドア仕掛ける中国と変わらんわ http://b.hatena.ne.jp/entry/365915261/comment/arrack
どこらへんがバックドアと一緒なのかが全然わからない。この反論になってない反論が俺には理解できない。
人んちに勝手に上がって電気使ってご飯作るようなもんだろ。マイニングを肯定するハテナーが多いが。 http://b.hatena.ne.jp/entry/365915261/comment/hammam
侵入してないので「上がって」はいないし、そもそもクラサバモデル自体、クライアントに対して確実に電気の使用は強いるものであり、ある意味では「人んちの電気」を使わざるを得ないので、この例えが何を言いたいのかがよくわからない。
んでちょっと、自分の頭の整理も兼ねて、ブコメやTwitterで見つけた「xxだから違法」という主張を少しまとめてみつつ、それらへの反論を書いたりしてみる。反反論が出てきたらいいなというか、「無罪派」が散々エントリー上げてるので、有罪派の人もエントリー上げて主張してくれると議論が深まるんだけどなという期待を込めている。
今のところこんな感じだろうか。繰り返しになるだろうか、倫理的、心情的、道義的にNGかどうかという話はどうでもよくて、注意喚起ではなくいきなり逮捕に至るほどの法的根拠、違法性がどこにあるのかを気にかけている。こんなもん社会的コンセンサスないし許されないだろという気持ちには同意するにしても、違法かどうかは別の話である。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
これから起こりえるであろうスタンドアローンコンプレックステロリズムにはとても対応できない。
ハセカラ騒動は日本におけるスタンドアローンコンプレックステロリズムの鏑矢であったにもかかわらず
その本質が悪ふざけであると言うだけで誰一人としてまともに取り上げようとしない。
ハセカラ騒動はなんJで3年近くヘイトを稼ぎ続けた末に身バレし炎上した「長谷川良太」と
その炎上を止められないどころか現在に至るまでの歴史的炎上にまで拡大させた無能弁護士「唐澤貴洋」に対する5年以上にわたる嫌がらせであり、
その二人への嫌がらせを行うという目的一点で基本的な行動の方向性が決まっていたために行為も過激化したが、結局死傷者の出る事件には発展していない。
沈静化しつつあるためこれからもそのようなことは無いだろう。
では仮に、その危害対象が「日本」や「日本の社会」である場合どうなるだろうか？
間違いなく大量の死傷者を発生させるテロに発展するであろうことは想像にたやすい。
毎朝のラッシュの満員電車で一度自爆テロをするだけで数十人が死ぬ大惨事となることは誰もが知っていることだ。( http://anond.hatelabo.jp/20150721142516 )
忘れられた就職氷河期世代( http://anond.hatelabo.jp/20170422041028 )はいつか必ずこの国や社会に一矢報いるために行動を起こすだろう。
しかも彼らは連帯する余裕は無いため組織だったものでは無いはずだ。
それ故に彼らが社会に危害を加えようとするときに共謀罪は彼らを抑止する法律とはなり得ない。
ある一定の意思の拡散という手段でISはすでに複数のホームグロウンテロリストを作り出している。
この国はどうやって彼らの「復讐」を予防するのだろうか。
