「バッドノウハウ」を含む日記 RSS

はてなキーワード: バッドノウハウとは

2019-02-20

オンラインエロゲ終了でオフラインプレイヤーを書いたら感動した

「対魔忍アサギ 決戦アリーナ」というオンラインゲーム(エロゲ)が終了する

まあ終了自体は仕方ない。このゲームゲームと言うには余りに大きな設計ミスを抱えすぎており、また、システム的にもかなり古くなっている。

だいぶ前からオンラインゲーム終了時にどうするか、という話はあるけど、あまり進展はない(ソシャゲ、ネトゲ等のサービス終了後のゲームの保存について考える、とか、米国でサービス終了オンラインゲームを著作権法例外とする動き―ESAは反対とか)。一つ根本的な問題として、本当にオンライン重要ゲームオフラインモードに余り意味がないのも大きい。

でも、対象エロゲ特に抜きゲ)なら話は別

何せ、最低限エロシーンだけ再生出来れば需要を満たす。

逆に、ゲームとしてのサービスが終わろうが俺には見たいエロシーンがあるんだよ!

anond:20190209083051 とかでも書かれていたけど、エロの質はいいし、ここにしかないものも多い。しかもそれは(ゲーム上で)自分が苦労して手に入れたものだ。勝手に閉じてほしくない。

……けど、運営コストを考えたらそうも言ってられないのはよく分かる。

というわけで、今こそオフラインプレイヤーの出番だ。

自分入手した分のデータダウンロードして、後は各人がローカルPC再生すればいい。

必要機能は大きく分けて、サーバからデータダウンロードしてくる部分、それからデータカードエロシーン)を閲覧するパートだ。

ちなみにこのゲームは初期に作られただけあって(?)、エロシーンに機能が少なく、BGV はおろか BGM も無い。オーバレイも1枚のみで、基本的に背景(シーン画像含む)と、テキストに 1:1 対応するボイスしかない。

これなら割とできそうな気がしたので保存・再生するソフトウェアを書いてみることにした。

というわけで出来たものこち

https://aakeeper.appspot.com 驚くほどあっさりできてしまった。

でも、今はできた物自体の話はいい。それより作る過程で色々感動したのでその話をしたい。

今や OSS には巨人の肩どころか常にジェット機に乗ってるくらいのツールが揃っている

今回使ったのはざっくり以下のもの

これらのツールに関して、自分殆ど学者だ。

Quasar FrameworkNode.js も Electron も使うのははじめて、他はちょっと触ったことあるけどそんな詳しくない。 ES もあまり好きでなかったので基本的には避けてきた。

にもかかわらず、全体で余暇時間2週間分くらいで出来た。

Quasar Framework は、とにかく物凄くよく出来ていてびっくりした。今回 Electron モードしか使っていないけど、本来はこれで SPA/PWA/モバイル(Cordova) アプリケーションが作れるという凄まじい対応幅のプラットフォームになっている。着手時に 1.0beta の予告だけあるというタイミングの悪さ(数日後に出た)だったので、 0.17 系を使った。しかし、それでも十分すぎるほどよく出来ている。

ES は今でも嫌いな点は多いんだけど、今回 async/await を使って感動した。これは素晴らしい。他の言語にも欲しい。

CoffeeScript趣味だけど、とにかく短く書ける点が素晴らしい。あれは終わったという人もいるが、記述量の少なさは js 系では他の追従を一切許していない。今回みたいな急いでいるケースでは、括弧の世話を焼いたり eslint おばさんと語り合う時間はない。CoffeeScript ならコンパイラが全部上手くやってくれる。

HTML5 ベースGUI は今や chronium の各種アクセラレーションのおかげで、並のポータブル GUI ツールキットよりずっと高速に動作する。

また、Vue.js + pug は非常に記述量が小さくて目的の画面がすぐ作れ、カプセル化がしやすコンポーネント再利用も容易だ。

Babel/Webpack は正にバッドノウハウを煮詰めて固めた感じだが、こいつがバッドな部分を吸収してくれるおかげで開発者正気を保てる。ただし追求しだすとSAN値が減る。

ユーザから見ると、Electron 製のアプリメモリをやたら喰う、少しもっさりしている、配布バイナリが巨大になるという問題は確かにある。

しかし、そうだとしても何より、とてつもなく高速に作れて、各種プラットフォームで割とちゃんと動く。

自分は色々初めてだったので結局2週間分くらい掛かったけど、前提知識が揃っている人なら本当に数日でできたりするんじゃなかろうか。

状況は良くなっている

つい数年前まで、クロスプラットフォームアプリケーション作成というのは本当に本当に大仕事だった。こんなに早く手軽に書ける事は無かったし、ユーザ側でもラインタイムインストール必要とか環境側のハードルも非常に高かった。

自分は今まで知らなかったけど、最早そういう時代は終わっていた。

もちろん過去に数多くのクロスプラットフォームフレームワークが登場しては消えていったのと同じく、Electron もいつかその仲間入りをするだろう。

でも確実に、びっくりするくらい状況は良くなっている。

興味があるけどまだ触ってないという人は、ぜひ試して感動を味わってもらいたい。

Happy Hacking!

2019-01-31

9ヶ月勤めたNTTグループ退職しました

タイトルの通り2018年入社したNTTグループの某社を退職しました。

2019年1月中旬正式退職したので、約9ヶ月間働いたことになります

記事では非常に主観的かつ局所的な話を書くつもりであり、一般性には欠けますのでご承知ください。

自己紹介

NTTグループの某SIer企業2018年度の新入社員として入社しました。

前年度までは大学院に在籍しており、情報系の研究を行っていました。

入社してから立ち位置としては一応システムエンジニアに分類されるはずですが、あまりシステムエンジニアらしい仕事は行いませんでした(これについては後述しています)。

退職までの流れ

2018年4月入社し、最初の2ヶ月間は新入社員研修を行っていました。

研修内容は大手企業あるあると言った感じで、挨拶練習名刺渡し練習ビジネス文章の書き方等を行いました。

周りは「研修が手厚くて良い」と言っていましたが、個人的には退屈なだけでした。

今振り返ってみると、この研修間中が最もつらかった様に思います

しかしながら研修自体は退屈であったものの流石に大手企業と言うべきか入社同期には優秀な方が多く、変な人間も少なかったため人間関係の面ではこれといった苦労はありませんでした。

6月になって研修期間が終わると正式部署配属が行われました。

この時配属された部署退職するまで在籍していたことになります

部署自体の詳細についてはこのエントリでは伏せますが、元々配属を希望していた部署であったため、配属当初は安心した記憶があります

退職理由

何か1つこれが決め手になってといった明確な退職理由はありません。

インターネットで言われるようなSIer業界の悪評についても内定から知っていて、実際に入ってみての感想としても「噂は真実だったんだな」くらいのものだったので特に入社したことに対する後悔もありません。

入社して詰まらない・つらい仕事であったら適当なところで辞めようと思っていましたし、その結果として詰まらない・つらい事象がいくつか重なったため退職するに至りました。

それらの事象を細かく挙げていくと切りがありませんが、そのうち幾つか分かりやすもの(且つ社内機密や違法行為に当たらないもの)を以下に挙げます

仕事の内容がほとんど雑務に分類されるようなものばかりだった

少なくとも自分想像していたシステムエンジニアとしての業務殆どありませんでした。

いわゆるSIerへの批判的な記事に挙げられるようなこと(Excelスクリーンショットを貼り付ける作業、何に使われるのか分からない謎の資料作成etc.)や、電話番等が主な業務でした。

新入社員に対して雑務を割り当てるというのはある種合理的な部分もあるとは思うので批判は控えますが、個人的には特に学ぶべきこともなく時間無駄に感じました。

一方でExcelスクリーンショットに関しては批判するべき部分があります

Excelスクショは「エビデンスを残す」という名目で行われることが多いと思いますが、システムが正しく動作たか顧客証明する目的であれば、結果ではなく検証をする方法提供するべきではないかというのが私の意見です。

スクリーンショットなんてものはいくらでも改竄可能もの(WebページなどであればDeveloper ConsoleHTMLを書き換えれば良い)であり、普通に考えればエビデンスとしての効力はないと考えられます

特に学べることがなかった

これは主にシステム開発・運用まわりについてです。

周りにはそれなりの年齢の方も多く、また社会インフラの構築を担うことの多い会社であるため、技術的な知識に造詣の深い方が多いと考えていたのですが、そのようなことはありませんでした。

大きな会社なのでそういった人も社内のどこかにはいるのかもしれませんが、少なくとも自分の周りでは観測できませんでした。

詳細は避けますが、技術的な知識に関してはその辺の情報学部生の方が理解していると思います

Linuxコマンドが分からない方向けにコマンドの打ち方をまとめた手順書(ターミナルエミュレータを立ち上げて、どこにユーザ名・パスワードを打ち込んで、どのボタンを押して...をスクリーンショット付きでExcelにまとめる)や殆ど問題を丸投げしている様な質問表等を作っていた時の心中は決して穏やかなものではありませんでした。

ファイル名の末尾に日付を付けるようなバージョン管理方法も噂では聞いていたものの本当に実在しているとは思っていませんでした。

また部署としては今後コンサルタントとなるような人材を増やしていきたいような雰囲気がありましたが、システム殆ど理解していない人にコンサルが務まるのかはよく分かりません。

個人的コンサルタントという肩書懐疑的なのもあります

環境に満足できなかった

主に常用していた端末周りの環境についてです。

使用しているコンピュータスペックがあまりにも低く(メモリ2Gハードディスク50GB、32bitOS)、まともに作業ができるような環境ではありませんでした。

Excelを開いたり、酷い時はIMEの変換機能使用した時にもコンピュータが固まっていました。

上で雑務殆どと書きましたが稀に開発をすることもあり、そういった場合特にスペックの低さによるストレスを感じていました。

私自身そこまで気合を入れて仕事をするような人間ではなく、むしろできることな仕事せず遊んでいたい人間ですが、やるべき仕事がくだらない原因で阻害されるというのはそれはそれでストレスが溜まるものだなと思いました。

自分だけでなく周りの人達環境でもそういったことは起こっていましたが、周りの人達はこの現象について好意的に感じている(コンピュータが固まるのを理由仕事をしなくても済むため)ようでしたので、その辺りの温度差も退職理由になっています

計算すれば高スペックコンピュータを導入するコストよりも、低スペックコンピュータを使うことにより生じる人件費無駄の方が大きいと分かるような気がしますが、あまり計算が得意な人がいないのだと思います

全体的な会社方向性に疑問を感じた

これは主にセキュリティ施策についてです。

昨今セキュリティ重要視され、セキュリティに関する施策予算が付くようになったのは良い点だと思っています

しかしながら、実施される施策的外れものと言わざるを得ないものばかりでした。

的外れならまだ良いですが、それはセキュリティリスクを高めるだけなのでは?と言った理解のない上の人間が思いつきで実施したとしか思えないものもあり大変疑問を感じました。

意味のない施策業務環境が不便になるのも見てる分には面白いですが、その中で仕事がしていきたいとは思えませんでした。

パスワードの定期変更や、暗号化zipファイルメールで送り続いてパスワードメールで送る等のバッドノウハウが未だに存在していることも知りました。

たこれはSI業界全体に言えることだとも思いますが、RPAとかDX(Digital Transformation)とか10,20年前に言うならともかく、今更言っても時代錯誤感が強いです。

良かった点

退職理由として不満点を挙げることになってしまいましたが、良い点もありました。

残業ほとんどなく休みが取りやすかった

これは部署プロジェクトに依る部分もあるみたいですが、少なくとも私の所属部署では早く帰ったからと言って咎められるようなことは殆どありませんでした。

最近労働時間に関する制限がかなり厳しくなっているようで、残業が多い部署は上から注意されているようでした。

有給休暇についても申請して拒否されるようなことはなく、むしろ消化が推奨されていました。

休んだことにより後から文句を言われることもありませんでした。

周りの人が良い人ばかりだった

上司や同僚から理不尽な扱いを受けるようなことは殆どありませんでした。

入社前のイメージパワハラモラハラは当たり前といったものであったため、非常に驚かされた部分です。

また少なくとも自分観測範囲では人種国籍性別による差別は行われていないように見えました。

福利厚生が充実していた

流石にNTT系列と言うべきか、福利厚生は充実していました。

色々ありすぎて私も全てを把握できていませんが、恐らく福利厚生に関しては国内企業ではトップクラスに充実していると思います

年収が高かった

少なくとも1年目の年収としては比較的高い方であったと思います

業務内容の割に高いとも思いました。

日本人の平均年収程度は貰えていたはずです。

私の場合残業殆どありませんでしたが、役職のない若手が残業をした場合残業手当が付くため(役職がつくと裁量労働制になる)、残業をした場合は更に貰えると思います

もちろん残業手当は働いた分だけしっかり付くようでした。

ただどうやら年収の伸びはそこまで良くはなく、聞いた話では20~30年勤続し管理職になってやっと1000万程度らしいです。

また国内大企業らしく厳格な年功序列制があるようでした。

まとめ

入社してから退職までの約9ヶ月間を振り返りました。

ただ勤務中はかなりささくれ立った心境であったため、こうして比較的穏やかに振り返ることができて良かったなと思う次第です。

巷ではSIer崩壊説みたいなものもありますが、個人的にはSIerは今後も続いていくと考えています

環境改善していって数十年後に「あの時辞めなければ...」と後悔することになると面白いですね。

今後の身の振り方については決まっていて、ソフトウェアエンジニアとして転職をすることにしました。

具体的な企業名や待遇等について詳細を書くことができませんが、年収については前職であれば20~30年勤続し管理職になった場合と同程度になります

最後になりましたが、読んでいただきありがとうございました。

2018-12-12

弊社accessすら入れてもらえないんですが

excelデータベースとして無理やり運用するためのバッドノウハウとかあったら教えて下さい

2018-10-31

Excelとか使う環境の人、バッドノウハウだらけなんだろうな…かわいそう。

100MB程度のCSVファイル開こうとしただけでクラッシュする表計算ソフト()なんかに縁がなくて、あぁよかった。

2018-10-26

増田プログラマー養成講座 その12 データベース参考書

前回は、MySQLphpMyAdminを使って、リレーショナル・データベースRDB)を少し触ってみた。

今回は、RDBの使い方や仕組みについて理解を深めるための資料を探してみよう。

 

本は、買う価値のある本と、買わなくてもいい本の2種類があるね。

  • 買う価値のある本:何度も読み返す本。
  • 買う価値のない本:1度読んだら終わりの本。(図書館で借りる。図書館にない場合は買う。読み終えたら古本屋などに売却)

どちらの本かは自分判断で決めよう。(1度で理解できない本は、何度も読み返すことになるだろう。)

 

初めてRDBを使う人のためのガイダンス

本書は,新人エンジニアデータベース全般について勉強したいとき最初に読む本です。

データベースに関する知識を広く浅く網羅的に紹介してた。

最初に読めば、DB全体を俯瞰する地図を手に入れたようなもの。その後の見通しが良くなる。

 

入門書(初級レベル

本書はMySQLをはじめて触る方を対象として,開発環境の準備からSQL基本的な書き方,PHPによるWebシステム開発まで,図解でわかりやす解説します。

MySQL入門書カラフルな図解が分かりやすい。

まずは、データ操作の基本「CRUD」(Create=追加、Read=取得、Update=更新Delete=削除)を理解しよう。

CRUDが分かれば、DBを使ったWebアプリを作れる。→ここがIT土方の最低レベルだぜ!

 

豊富な図解とていねいな解説により、やさしく・楽しくデータベースSQL学習できる入門書です。

本書は、データベース操作する問合型言語SQL」の文法練習できる。

SQLが読める&書けるようになれば、RDBを使ったプログラミングで苦労しなくなる。

 

 

 

上記2冊の入門書程度の知識を身に付ければ、RDBに関しては初心者から脱却できるはずだ。

RDBを使うプログラムを作るなら、まずはこの程度の知識クリアしておけば、十分だろう。


次の段階では、既存DBを使うだけでなく、「ゼロからDB設計、構築してくれ」と頼まれるようになるはずだ。

時間があったら、DB設計スキルを身に付けておこう。

(以下の話は、今の段階では無視してもOKRDBにある程度慣れたら読んでみて!)

 

 

 

ミックさんのDB

データベースの本はいろいろあるけど、「ミック」という人が書いた本はRDBの要点がまとまってるので、なるべく早い段階で一通り目を通しておくことをお勧めする。(ミックさんの本は買って何度も読み返してる。)

 

DOAデータ中心アプローチ

RDB設計方法はいろいろあるが、古典的手法として「DOA」(データ中心アプローチ)がある。

なぜこの古臭いDOAが、今でも重要なのだろうか?

DOAと、他の「OOAObject Oriented Approach:オブジェクト指向アプローチ)」「POA(Process Oriented Approach:プロセス中心アプローチ)」を比較した図を見てみよう。

OOAは、言い方を変えれば、

[ユーザー] ←→ [プログラム] ←→ [DB]

という流れになっている。

まりユーザーから見ると、間にある[プログラム]は、[DB]を包んでいる「ラッパー」でしかない。

=[DB]のデータ構造スキーマ)さえシッカリしていれば、間にある[プログラム]は取り替えてもあまり困らない。

 

RDBを使うシステムなら、DB設計プログラム設計よりも重要になる。

(後で[プログラム]を変更するよりも[DB]を変更する方が影響は大きい)

から今日でもDOAは十分に役立つ手法だと思って理解して欲しい。

 

DOAは、ざっくりと3ステップでやる。

  1. 分析会社業務などを分析して、データCRUDが発生してる所を列挙する。
  2. 論理設計データ間の関係分析して、「ER図」を作る。
  3. 物理設計ER図を基にして、DB設計する。

慣れたらER図を書かなくても、頭の中で思い浮かべるだけでもテーブルを作れるようになる。

 

最初DOAを知っておけば、今後他の設計方法を使うときでも、比較検討基準として使えるので、損はないはずだ。

それでは、DB設計の本を見てみよう。

 

DB設計(中級レベル

初級者が押さえておくべきDB設計の基礎知識ポイント正規化非正規化のケーススタディテーブル設計のやってはいけないバッドノウハウ、注意すべきグレーノウハウなどを丁寧に解説します。

DB設計入門書。著者はミックさん。

DOA正規化階層構造木構造)のデータの扱い方など、DB設計の基本を網羅的に説明している。

 

現場で使えるアイデアが満載 デキるDBエンジニアになろう!

私が設計スキルを付けるために実際に行ってきた「身の回りのものを題材にERDを書く」という方法サンプルを今回は8種類書き下ろさせていただきました。

手前味噌ではありますが、本書をお読みいただき実践していただくことで「実務で具体的に手が動く」というレベルに達していただけると考えています

DB設計入門書

DOAの考え方、ER図の書き方などが説明されている。

 

RDB理論上級レベル

RDBSQLは「関係代数」という数学が、その基礎を支える理論になっている。

関係代数」などを解説

RDBを改造したり、自作したくなったら、RDB原理を知っておきたい。

この手のコンピューターサイエンスの本って、難しくてつまらない本が多いけど、この本は図解が多くて、珍しく分かりやすい本だったw

 

ネット

本の情報は、出版された瞬間から陳腐化が進む。

最新の情報は、ネット確認することができる。

 

公式サイトオンラインマニュアル

自分が使うデータベースマニュアルは最も基本的な1次情報になるので、不明点があったらまず確認するようにしたい。

など、公式サイトオンラインマニュアルをチェックしておこう。

 

ミックさんの解説記事

ミックさんは、ネットでもDB技術論の記事を公開されており、参考になるかも?

(↑無料Webサーバー「Yahooジオシティーズ」は2019年3月閉鎖予定なので、読むなら今のうち?)

 

階層構造になっているデータカテゴリー情報など)をRDBに保存するとき、主なやり方が3通り紹介されてた。(上記の本でも紹介されてる)

  1. SQLで木と階層構造データを扱う(1)――入れ子集合モデル
  2. SQLで木と階層構造データを扱う(2)――経路列挙モデル
  3. SQLで木と階層構造データを扱う(3)――入れ子区間モデル

自分は(2)の「経路列挙モデル」が分かりやすくて、いつも使ってる。

 

…という具合に、ネット上の公開記事にも参考になる情報がたくさんあるよ。

(ここまでの説明URLを9個張ってしまったので、もうこれ以上URLを張れない。><

他にもGoogle検索などで役立つ記事を探してみよう!(唐突な締めw)

 

NoSQL

データストア(データを保存する道具)は、RDB以外にもいろいろある。→「NoSQL」とか呼ばれている。(自分検索してみてw)

RedisHadoop、ElasticSearch、OpenStack…いろいろな道具が発明されてるね。

RDB以外のデータストアを使うときでも、RDBと相違点を比較しながら学べば、取っ掛かりが持てて、理解スムーズになるだろう。

RDBは、知っておいて損はない。使いまくって、体得しよう!

 

まとめ

RDBSQLパズルみたいなものから、楽しんで学んで欲しい。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書 ←★今ここ★

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-12

anond:20181012113147

築地ロストテクノロジー建設されたうえに、運用バッドノウハウのかたまりで、

同じものを作り上げることはそもそもできなかったんだ。

2018-06-11

似顔絵で「その人の不細工な部分を強調すると似る」ってバッドノウハウというか、逃げじゃね?

それで金とるならいい気分にさせろよ。

2018-06-07

独占資本翻訳、就活エリートやんけ!

機械イノベーションバッドノウハウ

……なんてこの間までマクロ的な観点から俯瞰してたので、命を懸けてオンラインディクショナリーを引き、ブルーボトルコーヒーを片手に、Macを広げながら英文を訳してたんだけど、やりがいになって独占資本翻訳に投げたら意外に就活エリートで驚いた。ビジネス用語文章も、今最も影響力のある俺より付加価値が高くて、なんか生まれるのが遅すぎて悔しい。

ときどきB2B文字列誤訳、その後、銀座フレンチレストラン食事をするあたり、主にインスパイアしているのがどういうレイヤーなのかが窺えてほっこりしてコミットメントする。貴殿の今後益々のご活躍をお祈り申し上げます

2018-03-11

自動車教習所で(たぶん)教わってないけど教えて欲しかたこ

日常的に運転している人には当たり前のことばかりだと思うけど、覚えたのは免許取ってからだったような気がする。もう10年くらい前のことだから、今は普通に教えているのかもしれない。

2018-01-05

炎上の火元よりもそのスポンサー電凸して圧力かけるっていうのバッドノウハウだと思うんだよな。

真偽とか無視してとにかく黙らせられればいいって感じだし、スポンサーにもとばっちりだし。

2017-07-17

何が気持ちよくないかよりも、何が気持ちいか自分を語れよ!!!

https://anond.hatelabo.jp/20170716015351

世間にはセックスバッドノウハウと、極度に一般化されたテクニックが並ぶけど、そうじゃないんだよ。俺達が知りたいのは!!

お前だけの、最高のセックスを、お前の体験に基づいて語って欲しいんだよ!!!

どうすれば、俺はお前を気持ちよくできるのか、それが知りたいんだよ

2017-05-10

ざっくり言いたい人へ

Hatelabo::AnonymousDiary

はてなはてラボはてな匿名ダイアリー


ざっくり言いたい人必見!
俺氏ライブドアニュースソースを公開へ

 2017年5月10日 14時25分



ざっくり言うと


 もっとみんなにもざっくり言ってほしい


 ソース公開したら良くね


 ド素人からきったねえと思うけど優しい目でみてね


ソースを読む













<p class="font-l"><b>Hatelabo::<font color=#4296A5>AnonymousDiary</font></b></p>

<p class="recentitem"></p>

<p class="font-ss">はてなはてラボはてな匿名ダイアリー</p>

<br>

<p class="font-ll"><b>タイトル</b></p>

<p class="font-ss"><font color=#2C4F99>■</font> <font color=#2CAAF0>■</font> yyyy年mmdd日 hh時mm分</p>

<br>

<br>

<p class="box-bg-gr">ざっくり言うと</p>

<br>

<font color=#4296A5>✓</font> 内容

<br>

<font color=#4296A5>✓</font> 内容

<br>

<font color=#4296A5>✓</font> 内容

<br>

<p class="box-bg-bl2"><a href="hoge">記事を読む</a></p>

参考文献: はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ

2017-04-25

見た目の良い書類を作るのにエクセルを使うのはバッドノウハウ

人類TeXを覚えれば問題解決

追記)

勿論,覚えるまでのコストは高い.

一方で,エクセルを使っているあいマウスをカチカチやっている時間は,将来的にはTeXを覚えるための時間を優に超えるはずである

2017-04-17

http://anond.hatelabo.jp/20170417161610

ブラウザで見てることを前提に言うんだが、いっペん下までスクロールして、真ん中辺に戻すと読み込みが上と下に同時に伸びていくので流れなくなる。そこからポチポチキースクロールして読むと、どうにか読める。

バッドノウハウだけど。

2016-12-12

東京はなにか行動するときバッドノウハウ必要な街

日曜日の11日にサルバドール・ダリ展を見に東京新国立美術館行ってきた。12月12日までだけど最終日は平日だからサラリーマン日曜日の11日が実質の最終日。

16時くらいについたけど、えらく混んでた。なんと80分待ち。東京美術館は混むと聞いていたがまさかこんなに混むとは思わなかった。

遊園地でもないのに80分も待つのはさすがにつらいので、休憩所でコーヒーを飲みながら17時くらいまで待った。待ったが、行列が少なくなる気配がないので仕方なく行列に並んだ。

18時にようやく入れた。閉館時間は18時なのだが、18時35分まで延長されるらしい。だけど館内も無茶苦茶混んでいる。ダリシュールレアリスム時代の絵は緻密な描き込みが良いのだが、人が多すぎるのと観覧者が全く動こうとしないせいで作品は遠目でしかみれず。時間もないので全ての作品を駆け足で見た。じっくり見れなかったため、印象に残っている作品はまったくなかった。

混雑のせいで名画が台無し

東京美術館巡りしている人にこの話をしてみた。東京で著名な作家の展示を見たければ平日に見に行くか早起きをして朝に見に行くしかないらしい。地方美術館だとこんなに混まずにゆっくり作品がみられるのに。東京美術館では混雑のせいで名画の感動が台無しになっている気がする。

くだらない工夫(バッドノウハウ)で東京サバイブ

東京に来て5年くらい経つが、わかってはいたけど何をするにも混んでしまう。最初はあまり地元ではみられない人混みが面白くてよく出かけてたけど、もう休日は混んでいるところへ出かけることがなくなった。地元に住んでた頃は山や花火大会へ行ったり、休日駅前で買い物をしたり、美術館巡りをしていたのだが、東京高尾山もクソほど混む、イベントごとがあれば身動き取れないほど駅前も混むわで、ここ最近はあれだけ好きだったことを我慢するようになってしまった。東京では保育園の倍率が高いから、倍率が低い所へ引っ越したり「保育園へ入りやすい駅」とか調べてるんでしょ? それってバッドノウハウじゃない? 地元では待機児童なんてほとんどいないよ。

やりたいことをやるために東京さよならバイバイ

今は東京自分にとってただ息が詰まる仕事があるから仕方なく住んでいる場所しかない。いまはただ人混みがあまりない空いている地元自分が好きなときに好きなだけイベントごとを楽しみたい。

2016-07-22

一行の文字数制限メール自動改行する文化をそろそろやめてほしい

メール自動改行、また、それに対応するバッドノウハウの実行をそろそろやめてほしい。大いなる生産性無駄

びじねすまなぁが記載されたサイトたち。俺の意見は少数派らしい。

読みにくいなら受信側のViewで処理すべきなのに、なんで送信側で調整しなきゃいけないんだ…ウインドウを小さくすればいいだけじゃないか

もちろんpタグを使うときみたいに段落で改行するのは必要CR+LFを置換するのは、意図した改行の情報が失われてしまうからダメうまい正規表現があるかもしれないけど。

2016-07-10

政治レガシーテクノロジである理由

選挙日なので現代政治無意味さについて書こうと思います最初に言っておくと政治に傾倒しすぎている人を小馬鹿にしている文書なので反論とかあったら書いてくれれば良いんじゃないでしょうか。

 

政治レガシーテクノロジです。なぜならば科学では無いから。科学では無いので今後も施政者独断による政策を実行し、 結果のフィードバック無しに野放図に存在し続けるでしょう。政治システムは我々がその弱点を理解し手を入れない限り今後も何ら問題解決し得る存在とは成り得ないでしょう。具体的には科学事実と言える以下の要件政策および政策を裏打ちする理由は全く満たしていない為、政治システムが打ち出す政策とは社会システムに対する仮説の域を常に出ません。これはシステム開発のターミノロジーで言うならばテストコードの無いレガシーコード、 あるいは測定の無いリーンスタートアップあんまり変わりありません。

ここですぐ思いつく反論は「投票による民意から正しい」というのがありますが、これは全くこの議論文脈的外れになります投票とは民意を反映するメカニズムではあるものの、正しさに近傍させるメカニズムは一切具備していません。イギリスEU離脱国民投票結果は記憶に新しいですね。国家社会主義ドイツ労働者党投票によって生まれた事にも注目しましょう。投票とは諦めと熱狂のためのメカニズムと捉えた方が良いでしょう。そして科学数学投票などというアプローチなど一切採用してないのを良く見てみましょう。さらに言えば正しさとは何なのかという定義自体が70億人分あるということにも注目しましょう。さらに言えばその70億のあいまいな正しさと,実際に社会システム上でワークする正しさは別物である点に着目しましょう。政策の正しさってなんだとみなさんは思いますか?憲法準拠してることでしょうか?人々の幸福依拠している事でしょうか?憲法とは時代によって経年劣化しない永遠普遍のナマの事実でしょうか?「人々」のカテゴライズには観測者のエゴは入り込まないでしょうか?自然言語記述された憲法の「解釈」には観測者のエゴは入り込まないでしょうか?たぶん僕らは政治システム継続する限り「正しさ」の定義を動的に変更し続けなければなりません。立憲主義功利主義も今は正しそうだけど、 それは時間とともに修正する事が不可欠でしょう。この複雑な系における永遠に正しい事など神以外にわかりようがないのだから。ゆえに正しそうな物に近傍し続ける為に科学アプローチによる継続的フィードバックループが不可欠なのです。またシステム開発ビジネスオペレーションにおいて既に実在している「テスト」や「仮説検証型のアプローチ」は実用的であり有効であると判明していますが、それにも関わらず政治はこうした手法と無縁です。よってレガシー遺産であり旧時代遺物であり維持が困難)であると言えるわけです。次は我々が自然言語はいかに正しさを規定できないかを見ていきましょう。

分野を問わず物事の正しさを充足理由律で語る場合、我々は議論俎上で次の問題にぶちあたるでしょう。わりと有名なアポリアです。

インターネット上で発生する議論なんてのはまさに、このトリレンマの通りで一見正しそうな事を言っていても結局は「相手が根負けするまで議論継続する声のでかいキチガイ」か「権威である誰か」が議論に「勝つ(笑」という結果ばかりが観察できるでしょう。まれ科学事実根拠にした議論も無くはないのですが、圧倒的に多く発生している炎上というやつでは概ねこのような議論ばかりが観察できるはずです。独断独断のぶつかりあいなのでまぁ仕方ないですね。基本的には独断ゴリ押しする為の殺し合いなわけですから。そして政治システム、とりわけ議会が行う議論はこれと大差ないわけです。愚かですね。政治は一応の協約として「投票」により独断を防いでいると言えます議会が成立する前の投票に着目してみても投票とは正しさを導き出す事ができないわけなので(そもそも誰もが独断による正しさを持ち得るわけで)投票簡単に間違いを選択します。ゆえに自民党に怒り、民主党に怒り、そしてまた自民党に怒るのような愚を犯すわけです。科学はこの愚を起こさないために実験観測事実(上記の4要件)によって、無限後退を防いだり観測者のエゴ排除したりする為の協約を敷いています数学ではこれは公理系にあたるでしょう。これらはそれ以上理由を遡らないお約束事として存在します。このトリレンマ観点に立った場合、我々が判別可能な正しそうな物事とはお約束事に依存している仮の正しさであり、実は有限時間を生きる我々には理由の遡りを完全に停止出来る真の正しさ(ナマの事実)を判別出来ない事が分かります。そしてそれでもなお、そのお約束事が役立つ事実っぽいものを生み出す事を我々は経験的にも歴史的にも知っています。また、こうした科学分野のお約束事に比べ政治におけるお約束事(投票)がそれのみではそれほど有効機能しないことも我々は経験的にも歴史的にも知っています

さて、最後にこのレガシーテクノロジである所の政治未来においてましな物になるにはどうしたら良いかを考えてみようと思いましたが、僕にはその答えが「協約」も無いこの場で成立するとは到底思えませんでした。まぁ科学事実をどうやって役立つ形でフィードバック可能な形に実装できるかなわけですが、少なくとも協約も無しにこの場では実証不能な事を断言すれば独断による殺し合いを防げないのでこの文書では取り上げません。政治システムをテスタブルで測定可能フィードバックループ内包をしているシステムにどうやったらカイゼンできると思いますか?みなさんが必要だと思う協約を敷いた上でトラバブコメ議論してみてください。僕からは以上です。

 

追記とか

 

なんとなく民主主義否定してるように誤読されてる感あるので追記しますが,民主主義科学事実によるフィードバック仮説検証によって補強せよというのがぼくの主張です。あと協約の無い議論不毛だな〜という思いを強くしました。協約を誰か敷くかな〜と思ったけど誰も敷かないですしね。

 

返信とか

 

 

レスどうもです。仮説検証の無いオペレーションが野放図に続くからです。政治オペレーションとはそんな不確実な物で良いのでしたっけ? あとは仮説検証まで行かなくても実行したオペレーションテクニカル分析した結果すら乏しいですね。例えばアベノミクスに対する評価なんて個々人の政治信条が混ざりこんでおよそ再現性の無い独断論しか存在しないからです。消費税増税についても同様ですね。こんなものは我々の社会形成するための知識としては今後全く役立たないでしょう。逆にオペレーションの精度を問うているこの文脈において民主主義絶対視する理由ってなんでしょう?無限後退なっちゃますよ。

※/合理とは〜にたいする返信

 

追加レスどうもです。100字だとなかなか語る単語を選ばなきゃいけないだろうからお察しします。さて「目的をどこに定める」と言っているその目的ですが期待効果の無い目的は無いでしょう。たしかにそれは政治科学も同じですね。そして期待効果を発案するアプローチ手段として期待効果近傍するアプローチ政治システム科学事実要件を満たしたファクトから始まっていない以上, 精度に乏しいと話しているわけです。そして政治独断投票という脆弱な仕組みに依拠にしている以上, 科学アプローチよりは望んだ効果を得る見込みは薄いといえますね。

 

レスどうもです。なるほど。ではその決定はどんな理由によって決められるのでしょうか?非理性的な人々の気分で決まるのだと主張されるのでしょうか?ぼくはそれでは期待効果を得られないので(期待効果なるものがあるのかも怪しいが)あるべき姿じゃないと申してます。どんどん無限後退に陥りますねえ協約の無い議論は。これは勝ち負けのパラダイムに陥って根負けした人が負けて勝った人が快楽を得るパターンになる気がするなあ。続けますか?

houyhnhm  生政治とかちょっとモノ読んでから出直して来てほしい。社会システム論もかすってもいない。システム開発者としても中途半端な人だとは思う。

 

はい人格批判と受け止めました。ありがとうございました。初手のレス人格批判レスにあまり興味ないの提示してるのでご理解いただければと。こちらが提示した文のどの部分に対する反論なのか明らかになった時点で反応したいと思います。生政治がどの部分に掛かって来るかなどなど。よろしくどーぞ。

 

改訂履歴

2016/07/10 0:38:追記書いた。
2016/07/10 0:38:返信書いた。
2016/07/10 0:32:引用の見栄えを整えた。
2016/07/10 0:21:返信書いた。眠いですぞ
2016/07/10 0:00:返信書いた。眠い
2016/07/10 21:49:返信書いた。増田ブコメに返信はめんどいですねえ。
2016/07/10 18:25:ぼくの政治信条はどうでも良いので除去
2016/07/10 17:38:トラバの人がおしえてくれたのでカンマを全角に修正プログラマバッドノウハウとしてこうなってたのです。ぼくの人格きもいっすけどね!

2016-04-17

CSSインジェクション、おもしろく・ネタ的にやるにはそれなりにスキルいるんだなあと思った

閉じまくって追加しまくっても崩れるだけで綺麗にならなかったし

トラバ元のバッドノウハウはいろいろおもしろそうなので試してみます

インジェクションではなく、自分投稿内で

閉じたの戻した

2016-04-04

anond:20160403214125

おさがしの増田は見つかりませんでした

見つかりませんでした

見つかりませんでした

見つかりました


追記:参考にし増田

はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ

2016-02-16

バッドノウハウ

都内フルタイム共働きで両親遠方ってだけじゃ保育園に入れるのはほとんど無理って話だけど。

都心で無理なら郊外に引っ越せばいいじゃないっつか、何でやんないの馬鹿なの?って勢いのコメントつくよね。

引っ越しは実際かなり有効努力だし、正しい手段でもあると千葉市在住の自分なんかは思うけど、

でもそれを当たり前のこととして誇るようなのってあれだよね

バッドノウハウめいているよね。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん