はい、楽しいです。
よし、半自動でクラス宣言するシェルスクリプトが欲しいなぁという場合にこんな感じで処理します。頭の中をUNIXのパイプに切り替えて、こういう入力をこんな感じに出力ってコツコツ作る感じです。
- makedir2touch() {
- mkdir -p "$(dirname $1)" echo "" > $1}
- #パスをクラス名に変更
- path2class_name () {
- echo $1 | tr '/' '\n' | awk '{print toupper(substr($1,1,1))substr($1,2)}' | paste -d'_' -s
- }
- #テーブル名table_name () {
- echo $1 | awk '{print toupper(substr($1,1,1))substr($1,2)}'}
- #パスを親クラス名に変更path2parent_class_name () {
- echo $1 | tr '/' '\n' | sed '$d' | awk '{print toupper(substr($1,1,1))substr($1,2)}' | paste -d'_' -s
- }
このスクリプトは4年ぐらい前に書いたものですが、今でもメンテして時々使ってます。
楽しいです。
私は管理職で対外的には営業とコンサルティングをやっており会社からは自分の仕事に専念しなさいと言われてます。
でも進捗が遅れると、そうも言ってられず私が巻き取るのですが大体バッチをやります。
バッチの方がコード量が少なくなりますし隙間時間で進められる。
UI部分を書く時間なんて到底捻出できないので、そうせざるを得ないのですがプログラミングは楽しいです。
私のコーディングは
・データを連想配列で取り出す
・キーとデータから変数を生成させる
・変数の編集はビジネスロジックとしてテキストで定義する（配列化したりテーブルに押し込んだりする）
・ビジネスロジックを関数で実行させる
連想配列と可変変数、テキストを実行させる関数の組合せでビジネスロジック定義をプログラムから切り離す書き方で変数を使わないプログラムになります。
これをマリーエンキント記法と命名しプログラミングを楽しんでいます。
画面処理系も画面を配列として処理するアイデアがあるのですが取り組む時間が取れません。
以前、作った汎用一覧（一覧画面を5分で作れる）と汎用帳票（原価計算などの複雑な帳票でも1日で作れる）、汎用権限管理（通常の権限管理、ロールの概念をドラッグドロップで実装しただけ）を使い回すくらい。
私が辞めたらメンテナンスは？
この会社でやりたいことは組織を作ること、役員になることなので、それ以外は興味がないし後は野となれ山となれ笑
お客さんは会社ではなく私についてくるからメンテナンスは大丈夫です。
むしろバッチやAPI、特に計算アルゴリズムの開発のほうが面白いです。プログラム開発の醍醐味はやはり自動化、効率化を達成することです。GUIの開発では人が操作する前提なのでそれが余り味わえないと思います。
某会社に入場して間もなく1週間目のとき、5年間在籍者に手作業の仕事で「遅い」と言われたことがあるので、ここの人は皆強そうだ、頑張らないと駄目だなと思って、2ヶ月間を掛けて、構想から最適なプログラミング言語を選定してから、ゼロから選定された新しいプログラミング言語を学習して、テキスト処理の正規化、動的配列を利用して、3ヶ月目はテストを含めて実用化が確信できて、遅いと言われる手作業を20秒で終わらせるツールを作ったことがあります。
ルーチン作業をやりながら、家帰っても3時間を継続に資料を探して、作ったツールは主にテキスト処理です。プロトタイプは約6つ、そのうち2つ応用ツールを作って、他の作業も短縮可能になりました。中には1時間の手作業を3秒で終わらせたツールもありました。仕事が瞬時に終わったが、褒められなくて、案の定反感を買いました。5年間そこに在籍していた社員は、あの手作業を繰り返して、競速までやっている、その手作業の速度と正確さが自慢になったようです。たった2ヶ月間で「専門卒」に記録破られたのは、あまりにもかわいそうに思ってしまいました。
テキスト処理、バッチ処理は主にネットワーク系、Linux系が多いです。特にネットワーク系の場合は大量なテキストを処理するのでどうしても検索アルゴリズムが必要です。色々調べて分かったのは私が実現したい機能は「単語フレーズ」をパターンにした検索アルゴリズムが一番速いようです。（wikipedia）先人たちが既に完成しました。
私の構想では、あの位の量であの速度はまだ最速ではないです。データが整形されていないからのと、使うアプリがそもそも無駄な描画が多いです。残念ながら「遅い」と言われたので、では自分で再現できれば良いかなと思いました。
シェル芸人ってジャンルがあります。不特定多数の方に使って貰うにはGUIベースの開発が必要だと思いますが、開発処理ではCUIが楽ちんですね。
元々汎用機のバッチ処理メインで育ってきたので、ドミノ倒しのように処理が自動的に進むのが心地よいです。
テキスト処理系のバッチ処理楽しいですよ。
何故なら、業務系の場合一番シンプルにプログラミングスキルの差が出る所だからです。
テキスト処理は正規表現、データベースへの処理など、最低限必要かつシンプルなものしか求められないからです。
自分が業務システムに携わった事がある人を技術的に評価して欲しいと言われたら、まずテキスト処理を書かせます。それぐらいスキル差が出ます。
そりゃそうです。
プログラミングは問題を解決する手段なのですから、問題が解決できれば楽しいです。
質問に反する様ですが、バッチ処理の方が楽しめている自分がいます。画面も面白いのですが、OA系の画面はGUIになってデータ整合性のチェックとかが結構いやらしく複雑です。売上伝票等が良い例ですが、明細を入力する事に金額を計算し表示するのですが、購入数量により単価が変動する場合と顧客要件で単価の手入力を許す場合の数量を変更した時の動作をどう制御するか、又軽減税率（税率が異なると税率毎に集計して計算する必要があります）と税計算の方法（外税：内税：非課税：単品外税：単品内税）が混在する明細が入力される毎に金額と消費税を計算する事を考えてみて下さい。消費税の集計は顧客毎に異なるのが一般的ですから、顧客が変わるごとに消費税の端数計算を請求単位・伝票単位・明細単位とマスターを参照して切り替えます。この様な条件下でどのイベントで何を処理しなければならないかを判断しなくてはなりません。場合によってはエレメントにロックを掛けたり、外したりと結構いそがしいです。場合によっては行毎にセレクターの内容を読み替える（配列データをサーバーから取得する）必要さえあります。
多くのプログラムが入力する順番を決めて入力済みのところをロックしています。これにより、制御の組み合わせをかなり制限できますが、意外と利用者からすると使いにくい事が多いです。よくこれで金を取ってるなと思うものが殆どです。バックエンドも知識は必要ですが、意外とフロントエンドのユーザーインターフェイスの設計は奥が深いです（カーソル移動の順序やイベント発生後の位置等も自然であることが重要です）。時間が競っている時には鼻血が抜けそうになります。プログラミングが終わってもユーザーが納得するようにチューニングや説得が必要なケースがかなりあります。
バッチ系はデータの生成にかなり知恵を絞りますが、フロントエンドが何を欲しているかが決まった状態から着手するので（フロントエンドの概略設計が終了したタイミング）割とストレートにプログラミングできます。注力するところはデータの生成ロジックです。結構複雑なデータ処理をすることが有ってしかも夜間バッチとかではなく、フロントエンドの要求に対して速攻で応答するべく努力するのでガチのSQLで対応しています（DAOモジュール）。この上にバッチに相当するプログラム（CTLと名付けているモジュール）を組み合わせて JSON を返しています。データベースのデータを０次元とするとテーブルは１次元と考えることができます。複数のテーブルを絡めると２・３・４次元位になるものをうまく最大１次元（レコードの１次元配列）にして返すあたりを考えるのは結構楽しいです。
いきなり複雑なものを考えず簡単なモデルを作って検証しつつ積み上げて行く過程は今でも楽しく感じます。これは画面系のプログラム内でのロジックで実際にやったことですが、バッチで生産予定（複数：最大30工程）の日程計画を自動生成するロジックは Haskell で組んで試験はコンソール上で行いました。結果を JavaScript に移行してフロントエンド上で処理をさせています。でもこれってバッチ処理でできたロジックなのです。出来た時は嬉しかったです。
みなさんが楽しいと答えている中お恥ずかしいのですが、私は画面開発のほうが圧倒的に楽しいと感じます笑
あくまで個人開発の話ですが、こういう機能があったらユーザーはワクワクするだろうな〜と考え、画面をゴリゴリ作って「いい感じ！」となるので、テキスト処理の開発よりは好きですね。
もちろんコードを書くことも好きなのでテキスト処理系のバッチ処理もやれと言われたら楽しくやるのですが、必要に迫られなければやりませんね。
なので趣味では使いやすいUIはなんだろうな〜と頭をひねらせて画面を作ってます。
画面などの開発のほうが楽しいと言うお気持ちがわからないくらいです。プログラミングの楽しさとシステム開発の楽しさは別物だと思います。手間暇かければ良くなることが分かっているような問題領域で、無心に手間暇をかけてやると、自分の命じた通りに良くなっていく・・・と言うのがプログラミングの楽しさかと思います。システム開発の楽しさってのは難しい問題領域に落としどころを決めていくことかなぁと思います。
私はテキスト処理の方が楽しいです。Pythonは便利ですね。昔はPerlでデータの成形とか自動化するの楽しんでいました。これに関してはC言語でやるのは苦行ですね。
めちゃくちゃ楽しいじゃないですか！
テキスト処理系とかデータ変換系とかのバッチ処理系は可能な限りシンプルで変更に強く性能もバッチリ！みたいなのを作ろうと思うと腕が試される分野ですよね。
やっつけ仕事にしてしまう人の方が多い気はするけど。
画面系が楽しいところはデザインとか仕様にある程度決定権を持ってるときじゃないと感じないかな。
1時間かかる処理をちょっといじって5分で終わるようにできたときとか楽しいです。
画面も楽しいし、自分で考えたWebサービスつくってるときが一番楽しい。
楽しいですよ(^^)
前任者が手作業で３時間くらいかけてやってた客先提出データを生成する作業を引き継いだ時にプログラム起動で自動で終わるようにしたら凄く楽しいです。
プログラマは基本「怠け者」で「自分が楽をするためにはどんな努力も惜しまない」人なんです。
個人的には画面の開発のほうが楽しくないです。
「なんっで！CUIで操作もできん愚か者のために作業せなあかんのじゃー！！！」
と魂の叫びを堪えながらやるのは精神を摩耗させますね。GUI、キライ。故にアップル製品はすべからくダサくて心底嫌。
年寄りの大昔の若い頃の話なので参考になるかどうかわかりませんが、まだ画面とかそもそもなかった頃の話です。ある時失恋してかなり落ち込んだ時に、プログラム1本書いたら、ずいぶん心が落ち着いた、という事がありました。もちろんバッチ処理です（そもそもオンラインプログラムはごく特殊だった）
達成感というか、プログラムが完成すると「ああ、自分はそんなダメダメじゃないんだ」って思えますからね。
あと、バッチ処理でもずいぶん工夫が必要な時があります。というか、本当に単純な処理は、50年前でも、今のノーコード・ローコードみたいに、汎用プログラムがその組織内で作られていて、パラメータ切るだけで出来ることが多かったので、プログラム書くのは、自然何かしら工夫が必要なものということが多かったです。
自分はプログラミングの適性を思うと、人の何倍も劣っていると自負するくらいでしたが、BASICプログラムの数行を組んで、モニターに「？」マークが点滅して、入力待ちになった時はまるで「2001年宇宙の旅」のHAL9000と対話しているボーマン船長を思い出して感激しました。
自分で組んだので自画自賛、病みつきになって、人の何倍もかかりましたが、仕事で使えなかったプログラムは使えるレベルまで達しました。
これが適性が有ってもプログラミングに触れ合えてない人がハマれば、自分の何倍も早熟すると思います。
今のプログラミングは自分のやったモノとはレベルが違うでしょうけど、発端、キッカケだと思います。
子供の頃から食わず嫌いのなすびが、就職先の宴会で出たみそ汁に入っていて、上司の手前、子供みたいな好き嫌いを言いたくないので、すすって見たら思ったほどじゃなかった、とか、そんな程度でもあると思います。
楽しいですよ。自分の頭脳をデバッグできるから。
よくわからない点が繋がって全体像が少しずつみえてくるところ
知らない概念が出てきて理解に四苦八苦するとこ
何か解決したら作ったりすると、誰かが喜んでくれるところ
くらいかなあ
作ったものを誰かに使ってもらって評価された時など達成感があった時かなと思います。
数学が苦手な娘に数学が楽しいのはいつと聞いたら、問題が理解できてすらすらとけた時、だそうです。苦手でも、理解できてすらすらとけたら楽しく感じるものなんだなぁと思ったのでした。
昔は、最小のメモリしか使わないとか、一発でエラー無しでコンパイル出来たときや、コードコンプリートしたときだったと思う。
最近は、自分のコードを如何に書かずに済ませるかw
A2A3X
「1番」との事ですが、２つ思いつきました。
1.魔法使いであるかのように扱われる
同僚のほとんどが非技術者という環境で仕事をしてきましたが、そういう環境で働くプログラマは魔法使いであることを求められます。「急で悪いんだけど、会議があるから明日までにお願いできる？」だとか「ちょっと成果物を変更したいから、ちゃちゃっとやっちゃってくれない？」というフレーズで技術者を追い詰める人たちは、技術者が指を一振りして呪文を唱えさえすれば1日が50時間くらいに伸びると思っている可能性があります。
2. 使い慣れた「魔法の杖」を使えない環境に置かれる
最初から使い慣れた言語や業務ツールなどが完全に揃い、あなたの能力を120%引き出せるような環境で仕事をすることが許されることは稀です。わたしの場合、初めて使うキーボード配列、OS、開発ツールに改めて一から習熟する事を求められ、せめてエディタをインストールしたいと考えた時には長々としたフォームを埋めて申請を挙げる必要がありました。
まとめると、苦痛なのは自分が何をしているのか理解されない事、ですね。
0 コメント:
コメントを投稿