truth-kidding-you

ブログをどこで書くかさ迷っていまここ

負のスパイラル

感謝の10000時間の中の人のブログ見て


気がつくと技術を身につける時間がない、ほんとにない。仕事を通しての成長の実感がないことが、どれほど苦痛なことか、自分も経験があるのでよくわかる。

時間を自由に使える仕事に変えてゆきたい。建前ではなくリアルに。


普通のプログラマーに求めたいこと


お国事情が違うのであれですけど。
日本でプロプログラマーにはまず出会わない。

プロの対極にいるのが作業者

人数比
プロ>>作業者

当然と言えばそうですけど。ネットで技術系サイトを見てるのは大抵、プロ寄りの意識の方なので、あまり参考には…


作業者意識が強い方、プログラミングで生計を立てている方は、少なくとも言語仕様を理解しプログラムを書けるという一点だけは死守してほしいと思う。

次に、仕様をコードに変換できること。詳細設計と呼ばれる工程にあたるところができると望ましい。
おそらく大変困難な工程作業に感じると思われるが、生まれつきの才能か、地道な訓練経験が必要でしょう。

C++ foreach

VisualStudioではforeachが使える

C#VBから移行した技術者向けに用意していたのかと思いきや、msdnでははっきりと非推奨の記載が。
理由はわかりませんが、標準に従おうということなのかもしれません。

代わりに使うのは
「範囲ベースのfor」

for(auto v : container)

こっちのが見た目も快適ですね。

そして、標準ライブラリは

std::for_each

紛らわしい。けど、こちらは範囲を指定できるのでより有用

C++ ポケットリファレンス

C++ ポケットリファレンス


C#学んでみよう-パイザ・ラーニング 準備編-

プログラムの動きは概ね次のようになります。

  1. 入力
  2. 処理
  3. 出力

 

入力データを受け取る方法、出力する方法を覚えないといけません。パイザ・ラーニングでは、標準入力/出力を使用するというので、まず、それを学びました。

 

各問題とも「提出いただいたコードの実行(標準入力による値の取得、計算処理)→標準出力→正誤の判定」という流れになります。

 

標準入力

サンプルコードを見てみましょう。

http://paiza.jp/guide/samplecode.html

var line1 = System.Console.ReadLine().Trim();

 なるほど、4行読み込もうと思えばこうもできるということですね。

var line1 = System.Console.ReadLine().Trim();

var line2 = System.Console.ReadLine().Trim();

var line3 = System.Console.ReadLine().Trim();

var line4 = System.Console.ReadLine().Trim();

MSDNで確認しておきましょう。

Console クラス (System)

コンソール アプリケーションの標準入力ストリーム、標準出力ストリーム、および標準エラー ストリームを表します。

Console.ReadLine メソッド (System)

標準入力ストリームから次の 1 行分の文字を読み取ります。 

戻り値はSystem.Stringのようです。サンプルコードでは数字列から数値への変換をしているのはこのためですね。

 

Stringもヘルプで確認しておきましょう。

String クラス (System)

素敵なメソッドがたくさんあります。文字列操作のメソッドが充実しているのは素晴らしいですね。

 

標準出力

サンプルコードを見てみましょう。くどいところは省略しています。

System.Console.WriteLine("hello = {0} , world = {1}",  hoge, fuga );

// 結果

// hello = hoge, world = fuga

 

System.Console.WriteLineで出力できるようですので、もう一度System.Consoleのヘルプを確認してみます。

Console.WriteLine メソッド (String) (System)

WriteLine メソッド
WriteLine メソッド (Boolean)
WriteLine メソッド (Char)
WriteLine メソッド (Char[])
WriteLine メソッド (Decimal)
WriteLine メソッド (Double)
WriteLine メソッド (Int32)
WriteLine メソッド (Int64)

:(途中略)
WriteLine メソッド (String)

:(以下略)

WriteLineが様々な形式のオブジェクトを引数にとれますね。

 

...("hello = {0} , world = {1}", hoge, huga);

 

再びサンプルから{0}や{1}は何でしょう、WindowsDOSコマンドやVBAで見覚えがあります。

 

複合書式設定(MSDN)

複合書式指定機能をサポートするメソッドには、次のようなものがあります。

  •   String.Format 。書式設定された結果文字列を返します。

 

次のように出力用に文字列を整形している、と理解してよさそうです。

 

string outLine = string.Format("hello = {0} , world = {1}",  hoge, fuga );

System.Console.WriteLine(outLine );

 

 入力データの加工

入力されたデータは処理に適した形に変換する必要があります。数字列を数値に変換したり、文字列を単語のリストにしたり。ラーニングのお題をみながらこれは学んでいくことにします。

 

 

C#学んでみよう-きっかけ編-

C++?今はC#の時代だよ!

ソフト作るならC#だよ。
 
プログラマの定年35歳ということで、とっくに定年退職していますが、老後の嗜みとして何か言語を学んでみたいと日頃思っていました。ブログを綴るかたわらでC#の学習記録をつけてみます。
 
開発環境
当面はネットで色々学べるということで開発環境は構築せず、オンラインプログラム環境を利用することにします。最初に使用するサイトはPaizaです。
 
Paiza
 
Paizaは転職系のサイトですが、学習用のお題があるのでそれを利用して学んで見ようと思います。プログラマとして転職できるレベルにないですし、そのつもりもないので(そもそも定年しているし!)「スキルチェック」はしません。
 

白襟兵の志願残業問題

最近気になったエントリーから

 

各自が経営意識を持ち、利益に敏感で、営業職でなくとも営業感覚を持つことが期待される職場では、「意欲・適性・能力」というあいまいな基準で駆り立てられつつ、働き手は自らを複雑な職務配置のなかに投げ込み続け、労働環境の自律性を放棄しているのである。

日本的働き方における「フレキシビリティ」の矛盾 - 社会学者の研究メモ

 

元記事は「男女雇用機会均等法では「共働き」を実現できない」と、女性労働者の問題に言及した話であるが、現在の自分が感じている職場のもやもや感に響くものがある。

 

いわゆる社畜残業体質のある職場環境では、裁量労働で自由時間をコントロールできるはずなのに残業が多い。実態の能力が低いこともありえるが、それ以上に残業をしているのを疑問に感じていたところ。

 

白襟兵の志願残業問題

与えられたミッション、タスクを自分の責任として感じている。その結果、仕事を進める上で時間が足りない部分は、納期に間に合わせるために、「残業させてくれ」と志願しだす。上司は「残業するな」とは強くいわないし、反対する理由がみつけられない。

 

・成果物のレベルが過剰(つくりすぎ)

資料の体裁や見ばえから、ソフトウェアの微妙な改善まで。改善項目が無限にわきあがり、際限ないカイゼン活動に入りこむことがある。バックログの管理ができないところに、過剰に期待に答えたいという承認欲求が絡むと眠気と飽きが来るまで止まらないということになる。

 

・作業者意識

「経営意識」を持つ人間の対局にあるのが「作業者意識」を持つ人間である。いわゆるブルーワーカー気質であり、与えられた作業を粛々とこなすこと、こなせることが仕事の証明になる人たち。よく作用する人は何時間かかろうが可能な限り時間を使ってノルマをこなそうとする。よく行けばどんなに仕事を振っても必ずやり遂げてくれるが、悪く作用すると未完成でも納期がきたら終わり、ふたあけてからの悲劇もある。

 

・説明、説得、交渉の忌避。従順でありたい。と

「なせばなる」は営業トークでいくらでも言える。一方「ならぬものはならぬ」を言うとなるととかく難しい。これは仕事の対価を得る立場(発注者)が「ならぬものはならぬ」を聞きたくないが、聞かざるをえない。ということを理解をしなければいけない。仕事の受託側と発注側に必ず発生する論理である。

 

説明、説得、交渉を忌避するの場面は、おおよそ、2つの原因がある。一つは、単に、交渉が苦手ということ。日本人全般がそう。でも、交渉権が認められないならそんな責任うけちゃいけない。もう一つは、交渉にパワー(時間と、エネルギー)が必要ということ。そのパワーで残業すれば終わるじゃないか?!という論理になりやすい。特に時間に関する交渉の準備として、最低限「現状」と「見通し」を揃える必要があるが、日頃から現状把握と先々を読む、いわゆるプロジェクト管理ができていないと、準備に大きなパワーが必要になる。こうなると、巨大なToDoの山を見て挫折し残業に倒れることがある。

 

 責任と権限

仕事の成果に責任を持つことは理解しやすいが、その責任に対してどのような権限があるかは不明確なことが多い。裁量権の範囲がどこまでか確認しておくべきだし、実質の権限が責任にふさわしいかよく見極めたほうがよいのだろうし、仕事を依頼、割り振りする際にはどのような権利があるのかを折に触れ伝える必要があるのだと思う。

 

--

このように働き方の自由化は基本的には推進すべき課題であるといえるのだが、「働き方」に関する議論には必ずといってよいほどある難題がついてまわる。それが「生産性」である。

 

著者は、「生産性」の難題について、千差万別としているが、実際問題何がおこっているのか振り返ってみたくなった。これも考える。

フルスタック無理とか言わずにそこをなんとか

理想:フルスタックエンジニア

現実:触った見た、ぐぐった系

 

何かベース技術があるうえで肉付けしていかないと理想と現実のギャップに潰されて悶々としちゃう。フルスタックのフルがどこまでかって話もあるけど。