「変数」を含む日記 RSS

はてなキーワード: 変数とは

2017-11-23

メタナントカ

例えば「AB」という概念があった時, 「ABAB」「ABのAB」「ABに関するAB」という概念も成立しうる場合, その概念は「メタAB」と呼べそうである.

あたりがぱっと思いつくけれど, 身近な例でも応用できないだろうか.

意外と難しい.

2017-11-19

sellPrice

おう、ユーザーが売却するとき下取り価格変数をsellPriceと書くのやめろや

いや、一貫してればまあ構わないのだが、できれば店がsellするpriceと一発で区別つけられるようにしてくれ

2017-11-11

つかゲームGUI変数いじってるだけとかどうとでも言えるわ

rubyドキュメントあいかわらず糞と思うとき

動くコード乗せろよと言いたい

一番始めにみる要約のところなんかコピペで動かん。

たとえばHASHの下記のページ

https://docs.ruby-lang.org/ja/2.4.0/class/Hash.html

{s: b , ... }    
{"a+": b , ... }

「...」ってなんだよ略しすぎ。

bって変数いかエラー起こす

そんで、下記なんか修正すると動く

p r = {s: 'b'   , h: 'c'  }
p r = {"a+": 1  , "b+": 2 }

2017-11-10

おっさんメソッド引数なしで長くなる理由

どうやら「メソッド細かくして~戻り値変数作って~引数渡しして~」という行為が面倒くさいというか短期記憶で処理しきれなくなるようだ

引数なし戻り値もほぼなしのメソッドが5行くらい並んでる(使うデータや出力されるデータは外部のどっかの広域変数に置いてある)、というのはその間に何か挟まれるとカタマリとしてわけがからなくなるから

過去おっさんメソッド/サブルーチンが長いのは現代プログラミングに触れてない世代だったからという解釈があったのだが、ぶっちゃけ加齢が主原因であった


40歳になったからわかったわ

2017-11-09

anond:20171109115142

RailsとかLaravelとかの本やチュートリアルサンプルアプリ作ってなんとなく共通構造理解するしかない

かい流儀フレームワークによってそれぞれ違ったりするし、「俺がMVC解説してやろう」、つってアドバイスしてくる奴等もそれぞれ言ってることが違う

変数の持ち方にしても、DIとか出てくるし

原則は、画面に依存しない共通処理を切り分けておいて、機能追加や機能修正が行いやす構成にするってことだと思う

MVCモデルがよくわからない

正確には「じゃあコレをどう分けて書けばいいのか」がわからない

変数持つ場所とか引数受け渡しとかクラスの分け方とかそういうのがわからない

特に変数を持つ場所相手を知らなかったら相手に指示できないじゃないか

まとまってる本でも読むしかいか

2017-10-29

これから子供作っていこうと思っている

今の家は、妻と二人で住むためにとりあえず借りた家なのですごく狭い。

もう少し広い家に住みたいと思っていたが、子供を作るということを思い出したので子育てがしやす地域引っ越しをしようと思っている。

家賃と広さと子育てのしやすさ、保育所の入りやすさなどが変数になるんだけど、組み合わせパターン結構多いので大変です。

(僕のわがままから都内にある会社から近い場所に住みたかったのだけど、子育てというクエストが出現したので遠いところに住もうと思い始めた。)

結局のところ、何にプライオリティを置くかって話なんだろうけど、人生は難しい。

オススメ地域を教えてほしい。

2017-10-21

何でもかんでも揃えようとしないでほしい

プログラマなんだけど、なんでも揃えようとしてる人がうざい

よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「=>」みたいなのの位置

揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒

10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする

面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい

だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たとき結構大きな変更してるように見えたりするからちょっとイヤ

さらgrep かけようにも空白数が不定だから正規表現にしないといけない

正規表現書くの面倒だしそもそも遅い

大規模プロジェクトだと待ち時間が大きく変わってくる

んだけど、まあここまでは別にいい

他でも十分ある宗派の違いだし、まだ理解できる

この揃えるとき

aaa      : {
    bbbb : 100
    ccccc: 200
},
dddd     : {
    e:   : 300
}

みたいに(フォントによっては揃ってなく見えるかも)、ネストが違うのに全部を揃えようとするの、ホントやめろ

わかりづらい

上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい

せめて揃えるのは連続する行で同じ階層のものだけにしてほしい

上でいう aaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄

bbbb と ccccc みたいなときだけならまあ許せる



仏の顔も三度まで、

ここからは許せないレベルもの


(1) 文字数を合わせようとする

上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる

しか文字数が揃ってたらそんな必要はなく見た目も綺麗だ

きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない

5つ項目があって、4つが6文字単語で残りの1つが4文字だったとする

6文字にしたいからそれっぽい意味単語いか探そうとしてる

無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい

理解できない自己満足しか思えない

揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る

beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語比較ではミスの数が明らかに変わると思う

なのに、 enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい



(2) 単語の語尾とか

(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語勝手に変化させたものがある

例えばだが、語尾が1つを除き全部 -ly になってたとする

そうすると残り一つに無理やり ly をつける

なんなの?イン踏みたいの?ラッパーなの??

経緯を知らない人が見たら意味不明単語である

そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある



(3) 変化形無視

上の時点で英語を完全無視英語力のなさはわかっただろうが、さらにこういうのもある

過去形には ed複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う

それを完全無視変数名を定義するから見ててすごく気持ち悪い

プレフィックスis つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くとき本来の形で書くとエラーでるからさらイライラする

例えばこういうこと

readed, catched, taked, companys, boxs, mans, childs, fishs, classs

見てるとムズムズする

英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う

まあエラーメッセージdon't have ~ とすべきところを has not ~ とか書いてたくらいだからなぁ

これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、~~』みたいの出るから」と言って直させるけど、上だからどうしようもない

間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない

2017-10-19

BASIC!のプログラミング教育適応性について

題:BASIC!のプログラミング教育適応性について

副題:Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

少し考えてみたのでまとめとして投稿します。

01.はじめに

この文章は、Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

ついて記載しています

02.BASICとは

BASICプログラム初心者向け言語として1960年代に発表された古い言語です。

極めて簡単文法インタープリターによる即時実行や1970~80年代パソコン

無償で搭載されていたこから沢山の人に利用されていました。

しかし、簡単ゆえの機能の少なさと即時実行方式のための性能の低さやその後の

優れたプログラム言語発表によりBASICの利用は著しく低下しています

03.BASIC!とは

BASIC!はアンドロイドタブレットスマートフォン上で動くアプリです。

Google playからインストール可能無料で利用できます

BASIC!

https://play.google.com/store/apps/details?id=com.rfo.basic&hl=ja

BASIC文法踏襲していますが、Android向けに大幅に命令拡張されており、

GPS等の各種センサー情報取得やSQLiteデータベース機能WEBVIEWを利用

したHTMLCSSJS表示・実行など約500程度の命令群で構成されています

無料広告なしのアプリインストールするだけでこれらの機能が利用可能

インタープリターなのですぐに実行することもできます

04.BASIC!でプログラミング教育を行うメリット

メリットについては以下があげられます

a.BASICプログラミング知識を持つ人は以外と多い

 過去の栄光というかBASIC自体は広く利用された時期が過去存在パソコン

 だけでなくポケコンゲーム機等でも利用できました。

 BASIC!は基本はBASIC拡張であり文法変数の取り扱いにおおきな違いは

 ありません。

 その当時、少しであってもBASICを触った人は多いのでメンターとしての

 再教育は容易だと考えます

b.HTML,JS,CSS勉強継続してできる

 BASIC!は手続き型と呼ばれる非オブジェクト指向言語であり最新の言語

 とは異なっています

 BASIC!のネイティブ命令群だけだと他の言語へのスムーズな移行は難しい

 かもしれません。

 しかし、BASIC!にはHTML5アプリのようにBASIC!自体webViewでHTML,JS,CSS

 を動かすことができます。(HTMLモード

 HTML,JS,CSS現在Webの標準であり、進化を続けています

 特にjavascriptオブジェクト指向言語進化採用される領域フロント

 エンドからバックエンドまで広がっています

 

 BASIC!自体webViewは他のAndroidアプリ同様、chromiumベースAndroid

 システムWebviewの更新により常に最新化されています

 HTMLモードではjQuery,Angular,ReactなどのJSライブラリも利用できます

 最初BASIC!ネイティブプログラムHTMLモードJSを利用したプログラム

 とSTEPを踏んだ学習可能だと思います

c.インストール環境設定が容易

 前述の通りアプリインストールするだけで利用できます

 追加の課金プラグインなどは不要です。

 またAndroid2.3以降でインストール可能です。

 但しAndroid5.0あたりからAndroidシステムWebviewが導入されているので

 Android5.0以降の端末を選択する方が無難です。

 インストール後、環境設定をする必要もありません。

 端末のルート化も不要です。

d.Androidデバイス等が安価

 安いタブレットであれば1万円程度で新品が買えます中古スマホであれば

 更に安価です。

 またプログラムを作るのでキーボードもあった方がいいと思います

 キーボードも2~3千円程度で安価です。

 もちろんソフトウェアキーボードフリック入力など)でもプログラム

 作れます

 パソコンよりもはるか安価プログラミング教育が実現可能です。

e.子供Androidデバイスに慣れている

 iPhoneの登場以来現在の子供たちはタッチパネルAndroidデバイス

 慣れています

 通常のノートパソコンに比べ違和感は少ないと思います

 また教える大人側も日頃パソコンよりスマホを触る人は多いと思います

 教える側の負担も小さいのではないかと考えています

f.可搬性が高い

 ここで述べる可搬性とは別のデバイスで同じプログラムを動かす場合

 容易さの事です。

 BASIC!はインタープリタなのでソースファイルのみを別のデバイス

 SDカード経由等でコピーすれば基本的には動作します。

 仮にHTMLモード場合は併せてHTML,JS,CSSコピーするだけです。

 別のデバイスにはBASIC!さえインストールされていれば動きます

 BASIC!独自プラグイン拡張モジュールなどは特にありません。

05.BASIC!でプログラミング教育を行うデメリット

メリットだけでなくデメリットもあります。以下の通りです。 

a.性能上の問題

 BASIC!の実体Javaで出来ています。すなわちJavaよりは性能は悪い

 ことになります

 実際、大量の繰り返しや大量の文字列を扱うプログラムは性能が出ないので

 処理に時間がかかります

 Androidスマホタブレット自体パソコン演算能力には劣ります

 大量の実験データ演算するような教育には向いていません。

 但し、プログラミング教育には大きな障害にならないと思います

b.BASIC!自体の仕組みの問題

 BASIC!はプログラムを作るアプリである以上当然文法エラーを実行時に

 表示する仕組みになっています

 ただ一部エラーチェックが甘い部分もあり本来エラーとすべきところを

 そのまま実行する場合もあり想定外の結果となる可能性もあります

 次にエディタは単なるテキストエディタと同等の機能しかなく最近

 エディタにあるようなシンタクスハイライト入力補完といった機能

 ありません。

 ただ比較シンプルプログラムを作る教育では大きな影響は無いと

 考えています

c.一部機能に制約がある

 前述の通りHTMLモードではJSが動かせます。ただし制約があります

 JSローカルモードで実行されるという事です。

 非同期通信などを行おうする場合JSが実行時エラーになる可能性が

 あります

 またデータベース機能であるSQLiteへの操作についても文字型項目しか

 利用できない制約があります

 JSローカルモードのみなのは教育の事を考えると少し残念ですが

 それでも多くのフロントエンドJSは実行可能なので教育には

 使えるという理解でいます

d.参考となる文献がほぼない

 教育には教科書またはそれに準ずる書籍必要だと思います

 該当する書籍がないのが実情です。

 ただ1冊だけ日本語で書かれた電子書籍存在します。

 ■BASIC! ~ 分かりやすい教本で一から学べるコンピュータ言語 - AndroidSQUARE

 http://blog.livedoor.jp/an_square/archives/51887786.html

 BASIC!の文法自体は極めて簡単なのでどうにかなると思います

06.結論

上記の通り、メリット/デメリットを列挙してきました。

デメリットもあるものメリットの方が大きい印象です。

とくに教える側の負担が少ない点がメリットだと思います。 

 

2017-10-13

anond:20171013120525

ありがとうございます

日銀使って無理な財政出動して、株価を浮揚させているのに、経済再生成功したなどと抜かしているから。

説明変数としてどれくらい強いかは別の議論です。

野党の素晴らしい点を解説お願いいたします。

日銀トレードのこの後をどう処理するの? 国債残高を今後どうするの?

野党はどうするのでしょう?

>これらを踏まえて、(他の党の政策が良いとは思いませんが)自民党投票するのが良いという積極的理由があるなら教えて下さい。

わたしにも積極的理由がないので、野党の素晴らしい点の解説をよろしくお願いいたします。

anond:20171013110637

説明変数としてどれくらい強いかは別の議論です。

日銀トレードのこの後をどう処理するの? 国債残高を今後どうするの?

これらを踏まえて、(他の党の政策が良いとは思いませんが)自民党投票するのが良いという積極的理由があるなら教えて下さい。

2017-10-08

ダイエット

https://anond.hatelabo.jp/20171008132901

個人差ってのを知らない人は自分知識経験が全てだと思うよね

ダイエット本とか大体そう

 

食っても食っても太れない人、何をやっても痩せない人

両方を嘘つきと断じて目を瞑ってるのか?

個人差は強烈に存在している

  

俺は前回は84キロから54キロまでを1年半かけて落としたが

初月11キロ、2ヶ月目5キロ痩せた(ここまででだいたい半分)

残り半分落とすのに1年4ヶ月かかってる。それほどに変動する

 

食事量や栄養状態脂肪細胞数、いろいろある

基礎代謝も25%変動する、安易理屈を振りかざすな

俺は普通に食べると太るタイプだ(2000kcalで月1キロは太る)

 

ダイエット中に2週間位停滞するのは割とよくあることだ

理由は正直良く分からんが、似たこと言ってる人をネットで見かける

(というかあまりにも変数が多すぎるから経験則でやるしかない)

1ヶ月は流石に停滞しないと思ってる

1ヶ月変わらなければ、方法がまずいんだろう

 

あと体重計に毎日乗るのは良いことだ

じゃないと、誤差なのか本当に痩せてるのかがわからなくなる

 

プロテイン重要だと思っている

どうしてもダイエットをすると筋力もえげつない程落ちる

いか筋肉を維持したまま痩せるかだが、タンパク質だけをひたすら食事で得るのは難しい

まあおまけだけどな。ビタミン剤のほうが大事だ、特にBMI22当たりからは倒れそういなる

2017-10-07

技術負債

今、俺が抱えてる技術負債

前提:

社内システム在庫管理等をWebアプリで開発し運用している。

素のPHP+JavaScriptで、フレームワークは使っていない。

ライブラリはjQuery及びそのプラグインのみ使用

前任者・・・開発経験のない者 自主学習で見よう見まねで作った。

・・・上記システムを引き継ぎ無しで受け取る。開発経験あり。

問題点

(1)バグ、潜在バグが多くある

変数比較において型を含める厳密な比較を行なっておらず、

ユーザー入力した値によっては想定した動作と異なる事がある

MVCモデルオブジェクト指向?なにそれ?

(2)異常系が想定されていない

すべて正常なデータが投入されたという前提で稼働

ファイル削除にしても存在チェックや削除できたかどうかも確認していない

(3)コメントが無い

コメントがほぼ無いので埋め込まれマジックナンバー意味が解らない

迂闊にデータを触れない

(4)すべて絶対パスハードコーディング

ローカルテストする前提でコーディングされておらず

常に本番機で開発している

これらに対し、細かい分野でリファクタリングしている。

リファクタリング対応できないほど大きい問題リメイクするしかない

2017-10-05

結婚相手とは政治的スタンスも一緒のほうがいい

妻、あるいは夫として生活を共にする相手で、一致していたほうがいい志向として、

趣味価値観金銭感覚、あるいは家族関係とか、よく言われると思うけど、

最近のこの政局、国際情勢など、毎日波乱に満ちた状況の中では

まず必ず政治の話が家の中で出て来ると思う。

(出てこない人は選挙にも行かないのかな?自分たち未来あるいは子供がどうなっていてほしいとか考えないのか?)

そんな時、リラックスできる家の中で、ニュースとか見ながらぽろっと口にした言葉

共感を得られないというどころか、対立してしまうような、或いはどちらかが我慢するような状況は

精神的にかなり圧迫されるものがあると思う。

結局これも「価値観」に含まれるのかもしれないけど、

政治的主義信条をお互い確認しておくことは、長い人生2人で過ごすということの未来像を確認することだし、

子供が何人ほしいとか言う以前の、大前提として共有しておくべきポジションだ。

もちろんお互い人間が出来てて、例えば妻は保守的で夫が理想主義、とかでも、

それぞれ議論して補い合うような、建設的なディベートを、楽しんでやれるような夫婦なら面白いと思うけど、

そんなエリート夫婦はなかなか居ない。

一般庶民として、TVを見るかネットを見るなどして、だんだんと右・左に寄っていったりしつつ

日々ニュースに触れる中で生まれ感情を「共有」できることが、夫婦関係にはとても大事なんじゃないかと思う。

極端な話、旦那ネトウヨで、リビングでも嫌韓発言を悪びれもせず吐き、

それに奥さんは嫌悪感を抱きながらも黙って聞いてる・・・とかって状況は、

端的に不幸だし、既にもう「夫婦」ではないと思うんだよね。

趣味別に夫婦それぞれ好きなことをすればいい、

金銭感覚も、まあ支障がない程度でお互い認められる範囲ならいい、

でも、こう毎日刻々と変化があり、色んな変数や色んな意見メディア上にも存在し、

さら自分たちの行く末に関わってくるというイデオロギー的な部分については

一致してないと生活が、空間が、行き詰まると思うんだよね。

政治の話はかなりの部分、感情に関わってくるからね、御存知の通り。

あと同じ家族でも、親と子供で考えが違う、みたいなのは、むしろアリだと思うんだよね

親に対して独立心を持つこと、信条というもの子供が相対化出来るってのはいいこと。

でも夫婦対立なんてしても何もいいことないよ。

夫婦は「合流」して「共闘」してやっていくしかないんよ。

もし、家庭でも政治の話はNGみたいなのが暗黙のルールとしてあると思ってるなら、

それこそ生活政治を切り離してしまう、結果的日本という国を後退させていく、悪しき慣習の再生産だよ。

2017-10-02

急募】 area1にエクセル的なセル横方向にいくつ並んでるかの変数

rowsとかcolumnとかあのへんはわけわかららなくのでナシでおねがいしま

2017-09-24

anond:20170924130812

IntelliJデバッグ停止中にマウス乗っけるとメソッドチェーンのメソッド部分ごとに戻り値を表示してくれたりしなかったりするな

最初はなんて賢い子なんだと思ったけど意外とそこで詰まることがないのでいまいち使わない機能だった

めんどくさそうな処理は本能的にメソッドチェーンよけてバラして書いちゃうから

静的言語だと途中にローカル変数があってもなくてもあんま変わらんから

2017-09-19

anond:20170919161407

「何が雇用変数になっているのだろう」について答えるなら、それは「労働需要」で、さらに元を辿れば「景気」で間違いない。

問題は、制度的な制約によって、「景気」と「雇用」の間に重い「緩衝材」が挟まっており、「景気」がリアルタイムには「雇用」に反映されない(反応が遅れる)状態になっているということ。

なぜ雇用流動性は上がらないのか?

正社員有効求人倍率非正規雇用ほどではないが、上がっている

 

にも関わらず、雇用流動性面白いほど横ばいだ

http://www.mhlw.go.jp/toukei/itiran/roudou/koyou/doukou/16-2/dl/gaikyou.pdf

8ページ下図

 

何だろうこれは

リーマンショック時と今で、1〜2%しか違わない

おそらくこれ以上に好景気になっても、20%を超えることはないだろう

もちろんこの1%というのはそこそこでかいと言えばでかい

これはあくまで1年で辞める人の確率から、長期で見れば若干の変化がある

はいえあまりにも若干すぎる

人材市場インパクトなんて微塵もないだろう

 

何が雇用流動性変数になってるんだろう?

国民性

日本雇用流動性を上げるなんて不可能なのか

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-09-01

自殺は謎というか変数が多い。

失業率が高くても自殺率は低いという国もあれば相関してる国もある。

風土の近い東欧同士などでも国によって差が大きいし。

宗教の差で説明しようにも派による差もあれば別の地域で逆転してる場合もある。

日本アメリカでは低学歴ほど自殺やす統計が出てる。

多民族国家人種で差が出る場合もある。一方で単民族国家自殺率が高い場合もある。が、

また一方で単民族国家でも自殺率が低い場合も有る。

不景気ときに増える場合もあるし、減る場合もある。

2017-08-29

から理解に困難を要するとき以外の例え話は不要だし低学歴所作

だってことを本当に世間一般乳幼児から寝たきり老人まで広まって欲しい

必要情報を付加すんな変数が変わることを理解しろ例える前に脳を動かせ低学歴

現場からは以上だ

核爆発から身を守る方法について

同僚がグアムにいくというので、自身知識再確認も含めて核爆発から身を守る方法について対応をまとめる。なお、私の知識は、「米陸軍サバイバル全書」の第23章「核・生物化学兵器から身を守る」のみであることに注意されたい。また、内容を転載するわけではなく自身咀嚼した内容になっているため誤りが含まれ可能性もあり、また核爆発後のサバイバルに関しては、そもそも火の起こし方や水の濾過方法など、前提となる知識があるため、核だけを考慮しても生き残れない。なので、興味を持った方は原典を読むのをおすすめする。

核爆発前・直後

当然ながら、核爆発直後に致命的となるエリアにいた場合、取れる対応殆ど無い。核爆発により引き起こされる障害

の3種類あるが、攻撃目標タイミング(火球が見えてからでは遅い)がわからない場合、取れる対応は少ないだろう。

ただし、もし、事前の警報があり少しでも対応が取れる場合には、掩蔽物に隠れることが重要である。これは、爆風や爆風により吹き飛ばされた物体を防ぎ、熱と光を遮断し、核爆発直後(1分間)の深刻な初期放射線を減らしてくれる可能性が高いからだ。隠れる場所は丈夫なコンクリート製の建築物がよいだろう。

ここまでで生きている場合

生き残った場合、5分以内に放射線を遮ることの出来るシェルター(追記:後述するがこれは核シェルターに限らない)に入ることが重要になる。これは、高レベルで初期ガンマ線を放射する放射性降下物から身を守るためであるシェルターに入るのと入らないのとでは被曝量が全く異なるのである原典でも強く書かれているので引用しておく。

目安として、5分以内にシェルターに入るのが生死を分けると知れ。早くシェルターをみつけること――これが絶対不可欠である

P.273

その後の行動スケジュール

核爆発後にどれくらい活動してよいかの目安については原典引用する。なお、数値には余裕を持たせているとのこと。

P.276

掩蔽性能、水分食料の備蓄を考えると、シェルターとしてホテルショッピングモール選択するのが最適なのではないかと思うが、人が集まると考えられるので、その分物資の減りが早いとも考えられる。難しい所である

残留放射能対策

さて、行動のタイムスケジュールがわかったが、その後生き延びていくための残留放射能対策を考えなければならない。残留放射能対策は、放射性下降物起因の体外放射能対策と体内放射能対策に分けられる。

体外放射能対策

体外放射能対策として留意すべき変数としては、

の3点があげられる。時間半減期距離距離による減衰、シールドシールド材による減衰、を考慮する。ただし、放射性下降物が広い範囲に降っている場合には距離による減衰は期待できない、などはある。動く車があれば距離も稼げる可能性があるが、移動により被曝する可能性もあるし、現実的に考えてシールド、つまり十分な性能を発揮するシェルターを確保することが取りうる最大の防御となるだろう。

コンクリート建築物以外にも、厚み1メートル以上の土砂で覆った地下式シェルターは放射性降下物に対して最高の防御になると書いてあるが、そんなものは当然無いだろうから、他に下記のようなものシェルターになると掲げられているので、次善の策を取っていきたい。

P.275

身近にあるものを考えると、マンホール簡単に空くのかどうか知らないけど、開けられればマンホールから地下に隠れるのが良いのかもしれない。(※追記:マンホールはそんなに簡単に開かないとのことです)その他シェルター地の選択と準備法などは原典に書かれているのでそちらを読むように。

また、シェルター内に放射性物質を持ち込まないようにシェルターに入る場合は、衣服を叩いたり振ったりして汚染を除去すること。髪の毛は沿ってしまうのが良いかもしれない。

体内放射能対策

続いて放射性降下物を体内に取り込まないようにするための対策。ちなみに汚染された飲食物や傷から体内に入ったもの問題になり、呼吸によって体内にはい放射性物質はさほど脅威にはならないとのこと。

水の調達

水の調達大前提、以下の点に留意するとして、

水の調達方法は以下の通り。

食料の調達

放射線障害について

まとめ

例えば放射線障害について知っておくことで、むやみにパニックに陥らなくて済むし、「これくらいなら…」といった正常性バイアスからも逃れることが出来る。正しい状況認識を持ち、落ち着いて全ての知識を動員し、工夫し、生き残りのために行動しなければならない。生き残ろう!

2017-08-18

バージョン対応が出るかもしれないので、変数にプリフィックスつけましょう、自分が考えたプリフィックスではバージョン対応できませんが、みたいなの見て、この人、自分が言ってる日本語本当にわかってないんだな、という気持ちだった。

2017-08-08

やっぱ俺の書いたコードは最高だな

システムの改修をやっていて、ちょっとした改修なんだけどコードが汚いから大変。

処理単位サブルーチンにしないで、上から下までベタッと書いて超巨大なサブルーチンになってるし、そのでかいスコープのなかで変数の使い回しとかやってるし、変数初期化とかしないでいきなり参照してたりしてたりするスタイルから、使い回しとの合わせ技で(その行での)変数の値が有効かどうか判断するのに大変だし。

作業やってるうちに何年か前に自分の書いたきれいなコードがでてきて、今まで誰も手を入れてないで汚されてなかったから、そこの改修は一瞬で終わったわ。

やっぱ俺の書いたコードは最高だな。

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