最先端の技術を取り扱うイケてるIT企業のことはわかりませんが、少なくとも普通のSIer（業務システムを作っているITゼネコン）に関してはタイトルのことわざ通りだと思っています。
そろそろプログラミングでついていけなくて悩む新人が増え出す季節なので、このエントリーを書きます。
未経験でIT企業に入ると、初めの１～２年はプログラミングでついていけなくて悩むことが多いと思います。
研修をスケジュール通りにこなせない、同期に差をつけられる、基本情報の午後問題がわからない…等、色々悩みが出てくると思います。
しかし、私がこれまで見てきた限りは、実務をこなして３年経つと、多くの人は自然と実務で通用するプログラミング能力が身に付きますし、同期とのプログラミング能力の差も気にならない程度にまで埋まりますし、基本情報に合格できる地力もつきます。
研修に関しては、選りすぐりの新卒（大卒）を集めて外部から講師を呼ぶ元請け企業の研修ですら、半分ぐらいの人は自力ではスケジュール通りこなせません。他の同期に聞いてなんとかこなしているのが実態です。
（研修のレベルが特別高いわけではありません。Hello World!から始まる入門書を丸５日間かけてやるようなレベルです。）
仮に研修についていけたとしても、実務に入ると合計数百万ステップ以上にもなる業務システムの複雑さや、研修で習っていない文法に面食らうことになります。これもみんなが通る道です（私も通りました）。
元請け企業ですらこうなので、恐らく多くの企業はもっと厳しい状況だと思います。正直、初めの内はプログラムを理解できなくて当然です。
同期とのプログラミング能力の差については、これも初めの内はあって当然です。
未経験者が情報学部卒に太刀打ちできるわけがありませんし、情報学部卒でなくても元々できる人もいます（趣味でプログラムを作っていた名ばかり未経験者とか、内定時にこっそり勉強したとか、理数系が得意とか）。
しかし、これも１年で実務についていけるか３年で実務についていけるかぐらいの差でしかありません。
実務についていけるだけのプログラミング能力が身に付き、基礎さえできてくれば、元々持っている人間的な魅力（チームワーク）が活かされるようになります。
採用する側もそのことはわかっているはずなので、人柄重視で文系卒であってもポテンシャル採用しているのです。採用された時点で、腐らずに学び続ければいつかはついていけるようになる、と自信をもって良いと思います。
基本情報については合格率20%前後の試験なので、何だかんだで難しいです。新人にとってはハードルが高いと思います。
しかし、これも実務でプログラミングに関わって３年も経つと、大抵の人は合格できるようになってきます。
中にはどうしても基本情報が受からない人もいますが、そのような人でも応用情報には合格できます。
（応用情報は基本情報ほどプログラミング能力を問われないので、ある意味では易しいです）
応用情報さえ取ってしまえば外部からの評価的には問題ありません。
実務でついていけないと、他業界への転職を考える人も出てきます。
「IT企業に入ってみたけど、システムと向き合うオタッキーな雰囲気よりも人と向き合うピチピチした雰囲気の方がやっぱり好きだ！」とかなら性格の問題なので仕方ないと思いますが、「ついていけなくて…」が理由なら、１年前後でやめてしまうのは勿体ないと個人的には思っています。プログラムと向き合い続けて３年経てば追いつけるはずなので。周りの人もそれはわかってるはずなので。
仕事や趣味で２進数・１６進数を使っている身として伝えたい図
気まぐれで基数計算を解説している画像を検索していたのですが、公式めいた画像は見つかっても本質的な所を説明している画像は何故か見つけられませんでした。
公式だけではなく本質を知ることも重要だと思うので、この記事を書きます。
基数計算を本質的に表すとズバリこれです。
我々が日常で使っているのは１０進数で、10に達すると次の桁に繰り上がるという概念です。
対して、２進数は2に達すると次の桁に繰り上がるという概念で、ビットのON/OFFの２値で制御するコンピューターにとっては２進数の方が都合が良かったりします。
１６進数も16に達すると次の桁に繰り上がるという概念で、2の倍数となっている(１６進数２桁で256通り=8ビット=1バイトの情報を扱える)ため、これもコンピューターにとっては都合が良いものになっています。
「○進数は○に達すると次の桁に繰り上がるという概念である」ということさえ覚えておけば、公式を覚えていなくても特に困ることはないと思います。
（少なくとも私は仕事でも趣味でも資格試験でも困ったことはないです）
例えば、125を１０進数で表す時は
10*10*10の桁…1000より小さいのでここには何も入らない。
10*10 の桁…ここを1にすれば、125の内100は表現できる。残り25。
10 の桁…ここを2にすれば、25の内20は表現できる。残り5。
1 の桁…ここを5にすれば、残りの5を全て表現できる。
→125
と表すことができます。
２進数もこれと同じです。
例えば、7を２進数で表す時は
2*2*2の桁…8より小さいのでここには何も入らない。
2*2 の桁…ここを1にすれば、7の内4は表現できる。残り3。
2 の桁…ここを1にすれば、3の内2は表現できる。残り1。
1 の桁…ここを1にすれば、残りの1を全て表現できる。
→111(2)
と表すことができます。
以上のことは当ブログの読者層なら皆さんご存知かと思うのですが、２進数を知らない方が検索してたまたまこの記事を見つけて理解していただけたら良いなぁ、ということで。
----------------------
目次
サクラエディタのマクロが動かない場合→マクロの文字コードを確認
ある人が作っていたサクラエディタのマクロが動かない（全角文字の置換ができない）ので、うまく動くサクラエディタのマクロと見比べた結果、マクロの文字コードに原因があったので、メモ代わりに残します。
上手く動いたマクロはSJISで保存されていたのに対し、上手く動かなかったマクロはUTF-8(BOM無し)で保存されていました。
マクロの文字コードを変更した結果、上手く動くようになりました。
この調査で30分以上時間を取られたので、この記事が他の方の調査の助けになれば幸いです。
ちなみに、公式ドキュメントに思いっきり載っていることに後で気付きました。。
UTF-8(BOM付き)でも良いみたいです。
マクロについて
あるあるバグ事例：幅を持たせた条件指定の狭間に落ちるケース
コーディングをしていて表題のようなケースでバグになったことがあるのを思い出したので、注意喚起ということで紹介します。
有効桁数の考慮不足等で境界値の条件指定が完全にカバーされていないと、境界値付近のデータが来た時にどの条件にも当てはまらずに素通りしてしまうことがあります。
例えば、株価に応じて処理を変える必要がある場面において、以下のような条件指定をしたとします。
・株価が1円以上100円以下の場合、～
・株価が101円以上1000円以下の場合、～
・株価が1001円以上10000円以下の場合、～
一見問題のない条件指定に見えます。
しかし、株価が整数だとはどこにも書かれていません。
そして、株価は小数点第一位まで入ることがあります。
そのため、この条件指定では、100.1円のような株価が来た場合に、どの条件にも当てはまらずに異常な挙動を示すことになります。
なお、有効桁数ギリギリを突くケースで境界値テストを行っていれば防げる事例です。
金額の計算を行う金融系だとあるあるのバグなので、境界値付近の仕様には細心の注意を払う必要があります。
java：Windowsバッチからの呼び出しで対話式で実行できることの確認
まあできますよね、という確認です。
これができるなら、ちょっとしたツールを作成する時に幅が広がります。
【ソース】
javaソースとWindowsバッチは同一フォルダに配置する。
・javaソース（IOTest.java）
import java.util.Scanner;
public class IOTest {
public static void main(String[] args) {
// Scannerクラスのインスタンスを作成
// 入力としては標準入力(System.in)を指定する
Scanner scanner = new Scanner(System.in);
// 文字入力を促すメッセージ
System.out.println("何か文字を入力してください");
// 標準入力から文字取得
String inputText = scanner.nextLine();
//入力された文字を画面に表示
System.out.println("入力された文字："+inputText);
// Scannerクラスのクローズ
scanner.close();
}
}
・Windowsバッチ（IOTest.bat）
rem classファイルがなければ作成
if not exist IOTest.class (javac IOTest.java)
rem classファイル実行
java IOTest
pause
【バッチ実行結果】
「何か文字を入力してください」と出た時に、「moji」と入力してエンターを押下しています。
・実行結果
C:\tmp>rem classファイルがなければ作成
C:\tmp>if not exist IOTest.class (javac IOTest.java )
C:\tmp>rem classファイル実行
C:\tmp>java IOTest
何か文字を入力してください
moji
入力された文字：moji
C:\tmp>pause
続行するには何かキーを押してください . . .
オブジェクト指向とは現実世界を正しく捉えることである
と書くと色々物議を醸すことが多いのですが、本当にそう思う出来事があったのでメモ代わりに記事にします。
私の趣味であるゲーム攻略での出来事なのですが、既存のツールをベースに新たなツールを作ろうと思い、ツールの開発者の方にソースを見せてもらいました。
しかし、そのソースはバリバリの手続き型で書かれており、新たなツールに再利用するのが困難なものでした。
キャラクターのステータスを計算するツールがあったとして、画面上の入力からステータスの計算結果を単に画面に出すだけでなく、内部で「キャラクターオブジェクト」を作っていれば、色々と再利用の夢が広がります。
例えば、「キャラクターオブジェクト」を集めてパーティを疑似的に再現する、攻撃側の「キャラクターオブジェクト」と防御側の「キャラクターオブジェクト」を用意してダメージ計算ツールを作る、等です。
オブジェクト指向の入門書を読むとよく「現実世界を正しく捉える」というキャッチコピーが出てくるのですが、これは現実世界を正しく捉えること自体に意味があるのではなく、再利用性や影響範囲の限定を考えると自然とそうなる、「現実世界を正しく捉える」は目的ではなく手段である、と思いました。
前述の例でも、入力から出力を求める手続きの世界ではなく、現実世界をオブジェクトを利用して表現する世界でソースを書いていれば、自然と再利用が可能なものになったはずです。
なお、当該のツールについては、私が再利用可能なものを一から作ろうと思いました。
オブジェクト指向を実践から学ぶ良い機会にもなりそうなので。
テスト環境を使用する時の心構え
始めての現場でテスト環境に触れる時、テスト環境がどのような環境か良く分かっていないと知らず知らずの内にテスト環境を壊してしまいがちです。
このあたりのことは情報処理技術者試験の勉強をしても身に付かなかったりするので、あえて文章にしてみます。
【そもそもテスト環境とは】
その名の通りテストをするための環境のことです。
作ったプログラムをいきなり本番運用している環境に上げてしまうと、プログラムのバグでお客様に迷惑をかけてしまうので、事前にテスト環境でテストしてバグを発見・除去してから本番運用に乗せます。
なお、テスト環境の中には、バグの発見率を高めるために本番環境にできる限り構成を近づけた特別な環境が用意されることがあるのですが、そのような環境は「ステージング環境」と呼ばれることが多いです。
【テスト環境の一般的な構成】
テスト環境が一つしかないことはごく稀で、通常は複数のテスト環境が用意されています。
サーバやディレクトリ、ユーザ等を分けることで、複数のテスト環境を用意しています。
複数のテスト環境を用意する必要がある理由は、用途や案件ごとで別々の環境を用意しないと、自分のテストが他の人のテストに影響を与えてしまうからです。
用途で言うと、各々の開発者が思い思いにテストデータを投入してホワイトボックステストする環境、本番環境と同じデータを投入して業務面の確認を行う環境、日々バッチを回して運用面の確認を行う環境、といった形でテスト環境を分けます。
案件で言うと、リリース時期毎でテスト環境を分けることが多いです。例えば、5月時点の環境と6月時点の環境、といった具合です。
【開発者の心構え】
ここで開発者が心がけなければならないのは、誤ったテスト環境でテストしないようにすることです。
例えば、ホワイトボックステスト用のテストデータをバッチを回す用の環境に入れてしまったら、バッチが異常終了し騒ぎになってしまいます。
また、6月にリリースするべきプログラムを5月用の環境に入れてしまったら、5月時点の構成を再現できなくなってしまいます。
（5月リリースするプログラムに潜んでいたバグが6月リリースするプログラムの挙動で隠されてしまう、というようなことも起こり得ます）
誤ったテスト環境でテストしないためには、どのようにして環境が切り分けられているのかを知る必要がありますし、自分がどのテスト環境を使用するべきなのかを案件ごとに確認する必要があります。
環境の一覧表があったり使用するべき環境が仕様書等に書かれていたりすれば良いのですが、そのような文書が無いのであれば都度確認した方が無難です。
