「セミコロン」を含む日記 RSS

はてなキーワード: セミコロンとは

2017-02-26

プログラマな人に質問

最も得意な言語とその言語を書くにあたって、絶対にゆずれないコーディングルールを 3 つあげてください。

例えば、

  • if や for の { は絶対次の行
  • セミコロンは書かない
  • 終わりの ) はまとめて書く
  • 無限ループは while(1) じゃなくて for(;;)
  • int num;if(flag){num = 1;}else{num=2;} みたいなどちらか代入するだけのものは if じゃなくて条件演算子にする

と言う感じのもの

2015-10-12

セミコロンについて個人まとめ

●「日向清人の英語雑記帳3」のセミコロンに関する説明引用

セミコロンを使う場合は、セミコロンをはさんでいる二つのセンテンス間に主従の関係がない。

 共通のテーマのもとでそれぞれ独自の位置を占めています

セミコロンを挟む「 二つ のセンテンスが 共通のテーマで結ばれており」、

 forwardとbackwardのように、明暗、天地、苦楽、善悪のような「一対の対照的要素を左右に配置できる」ときにその真骨頂を示す。

ピリオドで 区切ることのできる独立性を備えていながら他のセンテンスと共通性のある二つのセンテンスをセミコロン区切ります

要するに、セミコロンは箇条書きみたいなものってこと。

各項目は平等地位にある。

●「越前敏弥の日本人なら必ず誤訳する英文」のA-01引用

These are my favorite animals: bears, for their strength; lions, for their courage; and monkeys, for their cuteness.

これだと、「お気に入り動物群」っていう共通テーマで、

①bears, for their strength

②lions, for their courage

③and monkeys, for their cuteness.

の3つが並列されている。

●「Grammar In Your Pocket Series Introduction」から引用

At home, you learned from Mom and Dad; in school you learned from Teacher. What you learned was what they knew.

→①AT HOME, you learned from Mom and Dad; ②IN SCHOOL you learned from Teacher. What you learned was what they knew.

英文法を学ぶ場所、状況」という共通テーマで、at home(家庭)と、in school(学校)がセミコロンで並列されてる。

2015-01-14

敢えてやってるプログラムの癖

pythonでもrubyでもbashでも、行末に必ずセミコロンを付ける。

大体どんな言語でもヒアドキュメントみたいな機能があって、SQL文を作成する場合はその機能を大いに利用するゆえ、その部分と区別をつけるため。

他のプログラマー増田には「自分オンリーの癖」ってなんかある?

2014-01-23

http://anond.hatelabo.jp/20140123200424

自分bashとかのスクリプト書くときに必ずセミコロン入れてるんだけど、感覚的には「。」と同じ意味に見えると思うんだ。

おなじことで、閉じタグ句点や読点みたいなものとして存在するのなら、それはそれで必要なんじゃないの?

2013-12-23

自分プログラマに向いていなかったのかもしれない

16歳の頃から趣味プログラムを書いていた。

一番最初はCだった。ポケコン付属のstdio.hしか無いCを使い倒して、PCを買って普通のCを始めた。

BCC32のセットアップが分からなくて電子計算機部の同級生PATHを通してもらった。

セミコロンがなくて1週間止まり友達相談したら本当に3秒で解決した。

ポインタが分からなくて1年間止まり、翌年C++を初めてから何かのきっかけで理解した。

あの頃は「黒い画面でカタカタやってる人たち特別感あってかっけー!!!1」ってのが動機だった。

中学卒業していたけど中二病だった。

社会人になった。

専攻とは大きく異なるけど、web系の会社プログラマという名前の職を得た。

学生時代とは違って、一日中コードを書いて、設計とか考えて、

土日で書いた趣味コードGitHubに上げてボコボコに叩かれたりして楽しく過ごせるんだろうなと思っていた。

確かに研修はそんな感じだった。朝礼が終わったらオライリーを見ながらプログラムを書き、終業時間を過ぎても勝手に書いていた。

それが終わったら、既存プロダクトを保守するところに配属された。

新しく作るなんてものはもう無かった。

バグ対応や小さな改修がたくさんあった。

それは別に悪いことじゃない。重要な事なのはわかっている。作って終わりではないのも分かっている。

でも自分じゃない誰かが、よく分かっていないままよく分からないものを作り続けてここまで来たのであろうそれを直すのは辛い。

「新しいコードに書き換えればいいじゃないか」というのはもっともだ。

でも新しいコードに書き換えたところで、新しいものを作っているということにはならない。

新しい機能、新しい製品を作っているわけではない。

利益を上げているというより、借金を返済している感覚だ。

その借金自分のものではない、なのになぜ自分が返済するんだ、というネガティブな考えが頭から離れない。

何より、コードを書かない仕事がとても多いのが辛い。

新入社員からというのか、コードを書いている時間よりそちらのほうがとても多い。

電話番もしていた。

新卒採用の手伝いもしている。

何のためにどんな仕事をするべきなのかわからないし、自分が何をしたいのかも分からない。

「土日で何か勝手に書けばいい」というのはそのとおりだ。

でも家に帰ってもネガティブな考えが頭から離れない。

仕事が遅いし、これと言える成果もあげていない。

また今週も何もしていないという考えで1時間くらいシャワーを浴びている。

水道光熱費がどんどんあがっている。

PCに向かい、手を動かし、プログラムを書くふりをしている。

公開できるような、会社が期待しているようなwebサービスとかでは無い。

会社のみんながこうでは無いのも辛い。

新しいコードを書いている人もたくさんいる。

なぜ自分はそうなれていないのか。辛い。

新しいものを作っていたほうが、新しいコードを書き続けていたほうが楽しいに決まっている。

感謝もされるだろうし、自分が中心にいる満足感だって得られるのだろう。

そのうえで「運用大事」とか考えるようになるんだろうな と妄想している。

何の論拠もない、僻みしか考えられない。

もう土日でwebサービス作るとか言うのはやめよう。

仕事もろくにできていないのに。

明日はどんな仕事をするのだろうか。

2013-10-03

Linux Mint 15 日本語化

こちらに丁寧に記載されていて、感謝の限りです。

注意は

$ wget -q http://linuxmint-jp.net/linuxmint-ja-archive-keyring.gpg -O- | sudo apt-key add -

$ sudo wget http://linuxmint-jp.net/sources.list.d/linuxmint-ja.list -O /etc/apt/sources.list.d/linuxmint-ja.list

$ sudo apt-get update

$ sudo apt-get dist-upgrade

の、最初の行の -0- は、英大文字のオーかゼロ。 2行目は 英大文字のオー。

最初-O-をオーでやったら「PGPファイルがみつかりません」とエラーになった。ここを数字ゼロにしたらあっさり"OK"と表示。このエントリに「ゼロです」を書いたものの、上記公式ページをみるとどうもゼロには見えない。念のためにもう1回ゼロでやってみたら「無効オプションだってさ(なので投稿内容を直した)。じゃあ「オー」が正しいのかよ?けど、おい数字ゼロでうまくいったんだぜ。最近、いろいろPC馬鹿にされてるわ。VirtualBoxインストールしていたので手打ちで実行させたから、コピペ可能環境ならいちいちこんなことで問題にならなかったのかな?まさかコピペのオーはOKで、手打ちのオーはNG

あと、プロキシ環境下でのインストールでは

su

スーパーユーザーになってから

export http_proxy="http://プロキシサーバ>:<ポート>"

として wgetプロキシサーバを教えます

さら

/etc/apt/ のなかに apt.conf というファイル作成して

Acquire::http::proxy "http://プロキシサーバ>:<ポート>";

最後セミコロン)の1行を書き込みますapt-get へ教えます

あとは sudo 部分のみ不要で、同じようにコマンドを流してやりましょう。

2013-06-15

VB.Netが好きだ

※以下、言語というくくりでの話ではなくて漠然PCプログラム作成環境全体を指して言っていると思っていただきたい

基本的には.Netが好きだ。

Web最初から意識して作られているし、標準ライブラリカバーされてる範囲が広いおかげでVisual Studio入れるだけでサクサクかける処理が多いので再発明を強いられる事態に陥りにくいのが感涙ものだ。

C++/CLIもやりたいことが割とリーズナブルコストでできるのでありがたい存在だ。

VB6は嫌いだ。

いろいろ拡張してくれた結果なのは知っているが、結局大事なところはダメ言語のままでMSから匙を投げられた存在という認識だ。

MFCも嫌いだ。

ひたすら面倒いし、出来たコードメンテナンス性も・・・メリットが今となっては動作の軽さだけだし(昔はむしろ逆の立ち位置だったんだろうが)。

だが、VB.Netは好きだ。

MSILを作るための道具であるがゆえに、VB6の痛い所が根こそぎ取り払われていると感じる。

C#でもいいのだろうが、セミコロンはなくても良いじゃない(あっても良いけど)。あと、オブジェクト変数宣言しつつ初期化するとき、"クラス変数名 = new クラス名()"になるのが

クラス名をSystem.XXXから書いているときには耐えられない。As New万歳

しかし悲しいかな、VB.NetC#に押されて絶滅危惧種だ。

TypeOfを使わなくちゃいけない時にはVB.Netが恨めしく感じるけど、そんなに頻繁じゃない。

他のデメリットにしても、表記がウザくなるだけで書けない処理があるわけじゃない(このへんがVB6と決定的に違うところ)

にもかかわらず、VB6イメージが悪すぎるのか、Javaから移住人口が多すぎるのか、C#ばっかりもてはやされる。

みんなもっとVB.Netソース書こうよ。「CLR」はマルチ言語からCLRなんだよ!?

2013-03-22

プログラミング出来ない奴ちょっと来い

プログラミング出来る方法教える。

世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

いや実際に "ない" というのはかなり語弊があるかもしれない。

しかし、通常この種の説明している本に辿り着くまでには多くの時間必要だ。

普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要概念を獲得するのだと思う。

例えば、「計算機プログラム構造解釈」や「実用 Common Lisp」、「コンピュータプログラミング概念技法モデル」などの書籍現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。

しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。

そして、"普通プログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

それは自分の作りたいアプリだったり、

クライアントから発注されたプロジェクトだったり、

上司から頼まれた仕事だったり、

業務を効率化させるための Excel マクロだったり、

授業で出された宿題だったり、人それぞれだろう。

このような目の前の問題を解決したい人達が、わざわざ LispMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。(ちなみに、LispMozart は上記の書籍で実際に使われている言語である。)

目的現在の問題を解決することであって、

新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。

もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。

純粋プログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。

今回はそのような”純粋プログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。


そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である

もしプログラミング学習限界を感じているのであれば、プログラミング学習方法が間違っている可能性が高い。

そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミング学習方法や上達するための正しいスタンス" を説く本はほとんどない。


できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも

より多くの人がより生産的にプログラムが出来るようになるためにも

そして特に、右も左も分からなかったプログラミングを始めたばかりの過去自分に対して、

効果的な学習方法プログラムする際の指針を書き記したいと思う。

それらは単に指針を示しているだけなので、

どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。

後はどれだけそれを実践に移し地道にプログラミングしていくだけである

正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。

プログラマレベルを以下の 3 つに分けてそれぞれについて説明していきたい。

1. 初心者レベル

プログラミング半年未満

・使えるプログラミング言語は一つだけ

ただし以下のことは出来ない。

・500行以上のコードが書けない

エラーが出た時の対処方法が分からない

写経は出来るが、自分プログラムが書けない

2. 中級者レベル

プログラミング半年 〜 3年

・1つ以上のプログラミング言語は使える

オブジェクト指向は理解している

ただし以下に当てはまる。

自分制作しているアプリケーション向けに "実用的なフレームワークライブラリ" を書けない

・1万行以上のコードだとスパゲッティコードになり、保守不能になる

・重複するコードが多く存在する

・適切なサブルーチン化できない

3. 上級者レベル

プログラミング歴 3 年以上

現実の問題に対して適切なデータ構造アルゴリズムを選択できる

抽象化について理解し、可変部分と不変部分を考慮した設計ができる

全てのプログラマはどれかのレベルに属するはずである

またそれぞれのレベルクリアするには明確な壁がある様に思う。

これらの壁を超えるにはどうすればよいかを説明する。

前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。


初心者レベルの人に向けて

完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。

検索エンジンで似たプログラム検索コピーペーストする

・本に載っているプログラムをそのまま書き写す(いわゆる写経

上のような行動を行なっているだけでは、いつまで経っても自分プログラミングが出来るようにならない。

なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。

それは、【プログラミング言語モデル】を自分の中に作ることである

プログラミング言語ルールの塊である

それは普通言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。

のしきたりを学べば書けるようになれる。非常に単純だ。

それなのに、なぜいつまで経っても書けないのか?

それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないかである

特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである

それは例えば、日本語を話すことと似ている。

友達と会話する時、頭を使っているだろうか。

それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。

プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。

もちろん日本語話せるだけでは、ミーティングプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。

それには以下の点を意識してプログラミングすればよい。

・"何をしたい時" に "どう書けば正しく動くか" というデータベースプログラミング言語モデル)を自分の中に作ること

このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。

1. エラーをたくさん出す

2. デバックの仕方を覚える

3. 小さく動かして確かめ

4. Google を使い倒す

まり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである


これらについては以下で詳しく説明するとして、

まず最初初心者ありがちな間違いをいくつか列挙してする。


関数メソッドをたくさん覚えなければいけない

無理して覚えなくてよい。

プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。

よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである

覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。

しろ実現したい処理が既にメソッド関数として提供されていないか、調べる力の方が大事

エラーがいっぱい出てつらい

全く問題ない。

以下で述べるようにエラーとどう付き合うかが非常に重要

写経をしなければならない

教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。

上記でも述べたように、これからまり無駄努力をしないことを願って言えば、

写経にはほとんど意味がないと思って取り組んだ方がいい。

写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。

なぜならば写経は "作業" だからだ。

そこに "言語モデル" や "思考" が伴わないと意味がない。

”思考” が伴わないとただの書き写す作業をしているだけだ。

自分の中に "モデル" が出来ていないので、いざ自分プログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。

写経はそもそもプログラミングに対するスタンスプロセスのもの勘違いさせる危険性をはらんでいるいる。

写経する場合、書き写しの間違いがなければプログラムは問題なく動く。

しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。

そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラム完璧ものにしていく。

書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。

また、以下で述べるようにエラーが発生した場合デバッグ作業は非常に重要であるだが、そのための作法写経から学ぶことができない。

なぜならば、写経中にエラーが発生した場合教科書自分で書いたプログラム間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である

それでは、デバッグ方法言語モデルを作るとても大切なプロセス経験できない。

ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである

とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。

さて初心者が陥りやすい部分については説明したので、

今度はどのように "言語モデル" を自分の中に作っていくかについて説明する。

1. エラーをたくさん出す

初心者エラーを出さない様にと慎重にプログラミングしようとしがちだ。

はっきり言うと、それは間違ったプログラミングスタイルだ。

特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。

PHP で例えると、

printf の書式だとか

文末に付けるセミコロンだとか

function はネストできないとか

変数には $ を付けなければならないだとか

グローバル変数関数の中で使う場合は global 宣言するとか

などである

初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。

例え今回作っていたプログラムエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。

しかし、それでよいのだ。

エラーを修正することの繰り返しの中で、その言語モデル自分の中に出来てくる。

そのようなトライアンドエラーを繰り返えすことで、"言語モデル" は文字通り体の中に染み込み、プログラムだんだんと書ける様になっていく。

おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。

誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。

そして最終定期には、難なく自転車を乗りこなせるようなっている。

プログラミング言語を学ぶ時も同じである

最初は何度やってもいろいろなエラーが出てくる。

それらのエラーを地道に1つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。

そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。

自転車も本を読んだだけで乗れるようにはなれないのと同じで

プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。

それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。

そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。

早めにそれに気付いて受け入れる必要がある。

2. デバッグの仕方を覚える

さてエラー重要性については上で強調した。

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。

期待しない動作をした時のデバッグという。

まずいちばん基本的で一番重要デバック方法printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめ方法である

僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグ重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである

初心者からこそ、デバッグ方法論や開発環境をきちんと整えるべきである

ほとんどの言語処理系では、デバッグ作業を支援する機能提供している。

からなければ、"言語 デバッグ方法" でグーグル検索してみればよい。

例を挙げると、

C言語だったら、gdb

PHP だったら Xdebug

Ruby だったら pp モジュール

Schemegauche)だったら #?= デバッグ

javascript だったら firebug

言語はいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

これは無益時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。


3 小さく動かして確かめ

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。

その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。

そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。

そのためまず小さく作って小さく確かめ部品を組み合わせてプログラムを作っていくことが大事になる。

一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。

ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢検討してみるべきだ。

"Small is Beautiful"

これは非常に有名な unix (という OS)の設計理念である

unix開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。

まだプログラミング経験の浅い人も、これから偉大な開発者経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。


4 Google を使い倒す

先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。

おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。

原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。




現実プログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事能力とは、実は "忍耐力" だろうと少しばかり思っている。

でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。

そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。

ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。





2012-12-15

Evernoteノートブック並び順(記号

Evernoteノートブックで先頭文字の並び順ってどうなってるのかなあ、と思ったので調べてみた。

OSとかの環境による違いはあるかも。

 _(アンダーバー)
 -(マイナス)
 ,(カンマ)
 ;(セミコロン)
 :(コロン)
 !
 ?
 .(ピリオド)
 ‘(シングルクォート)
 “(ダブルクォート)
 (
 )
 [
 ]
 {
 } 
 @
 *(アスタリスク)
 / 
 &(アンパサンド)
 #
 %
 `(アクサングラーヴ)
 ^(ハット)
 +
 <(左山カッコ)
 =
 >(右山カッコ)
 |( パイプ)
 ~(チルダ)
 $

2011-06-18

http://anond.hatelabo.jp/20110618142228

プログラム下手ってどうやったらなれるんだろう?

知らない言語リファレンスぐぐりながら適当に作ってもまともに動かない方が難しい。

行末にセミコロン付けちゃったとか変数宣言をちょっと間違ったとかはやるけどさ。

2010-11-19

セミコロンとハイフンの入れ替えで快適タイピング

セミコロンとハイフン

QWERTY配列キーボードタイピングするとき、ホームポジション右手小指の位置にはセミコロン(;←これ)が存在します。

「これここにある必要ある?」と前々から思っていました。せいぜい、泣き顔(;;)を作るときに楽なくらいで、指をまったく動かさなくても打てる位置に置く必然性を感じなかった。(英文だとよく使われるんだと思う)

逆にハイフンのキー(キーボードとかニューヨークとかの伸ばす記号(長音符)を入力するときに使う)は右手ごとひねらないと打てない。セミコロンより圧倒的に使用頻度は高いのに。

それなら、セミコロンとハイフンを入れ替えればいいんじゃない

というわけでKeySwapというソフトを使って入れ替えてみました。

スムーズに長音符が打てるのがこんなに快適だとは。これは素晴らしい。

自分パソコン以外でやるわけにはいかないけど、それでも快適です。

やってみよう

今回使ったKeySwapはとても簡単にキーの入れ替えができます。入れ替えたいキーを押して指定するだけ。難しいことは一切ありません。

ただし、使うときはちゃんと同梱のreadmeを読んでくださいね。

2008-07-27

Webアプリ脆弱性オタがふつーのSE彼女脆弱性世界を軽く紹介(ry

まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、

「オタではまったくないんだが、しか自分のオタ趣味を肯定的に黙認してくれて、

 その上で全く知らない脆弱性世界とはなんなのか、ちょっとだけ好奇心持ってる」

ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために

説明するべき10パターンを選んでみたいのだけれど。

(要は「脱オタクファッションガイド」の正反対版だな。彼女脆弱性布教するのではなく

 相互のコミュニケーションの入口として)

あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。

できれば、秋葉原とか筑波とかから突っ込みはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。

あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。

プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。

そういう感じ。

彼女の設定は

セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。

ひろみちゅとか、はまちちゃんてなんだろうという好奇心もある

サブカル度も低いが、頭はけっこう良い

という条件で。

まずは俺的に。出した順番は実質的には意味がない。

XSS

まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。

ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。

この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報彼女

伝えられるかということは、オタ側の「真のコミュニケーション能力」試験としてはいタスクだろうと思う。

MITM, DNS Rebinding

アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性(そうオタクが思い込んでいるだけ。実際は全然受け入れられない)」そのもの

という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには

一番よさそうな素材なんじゃないのかな。

Webアプリ専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう?」って。

パストラバーサル

侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを

彼女に紹介するという意味はいいなと思うのと、それに加えていかにもマニアック

「よく眼にするけどあまり実害の思いつかない」/etc/passwd

「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow

の2ファイルをはじめてとして、オタ好きのするファイル世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。

CSRF

たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。

そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性日本で大人気になったこと、

ひろみちゅがはまちを焦がしたのは事故か、わざとか?

なんかを非オタ彼女と話してみたいかな、という妄想的願望。

メールヘッダインジェクション

「やっぱりWebアプリ脆弱性個人情報DBなんかがあるサイトものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」

でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから

断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、

その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまから

ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが

Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。

なのに、安全APIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても

自分過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、

親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。

ディレクトリリスティング

今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。

SQLインジェクションよりも前の段階で、個人情報漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、

こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、

別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、

いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。

OSコマンドインジェクション

UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。

ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、

からこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。

「侵入先のコンピュータコードが動いてこそなんぼ」というクラッカー感覚今日さらに強まっているとするなら、その「クラッカーの気分」の

源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、

単純に楽しんでもらえるかどうかを見てみたい。

Hiddenフィールド改ざん

これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。

こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか

突っ込みを誘発するか、というのを見てみたい。

SQLインジェクション

9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。

XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と

なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。

というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら

教えてください。


「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。

こういう試みそのものに関する意見も聞けたら嬉しい。


Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本

 
ログイン ユーザー登録
ようこそ ゲスト さん