自動化するかの判断ポイント

個人的なもの。

 

事務処理やらサーバコンソール操作関係において

マクロ作ったり、シェルやらスクリプトやらを組む前に

「それが必要なのか？」を判断するポイントを整理する。

 

・その作業は繰り返し実施するか？

1発モノの作業であれば作業工数＜自動化工数となる。ほとんどにおいて。

作業精度向上を狙うなら、箇条書きチェックリストのテキストで概ね十分であることが多い。

その作業自体を1年程度のスパンで考えて4度以上実施する想定が立つ場合に自動化を考える。

(とは言え頻度が低ければ低いほどチェックリストで事足りることが多いけど)

 

・気乗りのする作業か？

個人的に以前と同じような作業を繰り返すこと自体が苦痛であるため繰り返し実施と半ば被るのだが、

気乗りのしない仕事ほど自動化作業にして多少モチベーションを維持する。

 

・横断的な作業であるか？

同じような繰り返し手順を複数台のサーバに繰り返す等にも当てはまるが

Excelのシートと、Webフォームと、サーバコンソールとと複数横断する作業は

切り替えで割と作業速度と精度が遅くなる。

その場合、どちらかの操作量を減らすためにシェルやスクリプトを書くことがある。

とは言えやっぱり一発物をフルスクラッチで書くのはコストがかかるため、この場合は使い回しできるかが判断に混じる。

 

個人的にはざっくりこんなところで、やって損はないかなと思えば何か書き出すようにしている。

ただ技術的・規約的(ルール的)に難しい場合もあったりするので、その辺りで引っかかる場合はやらない。構成管理対象なんかはよく止める例。

 

まあ、チマチマした気乗りしない作業でもなんか能動的な観点を持っておくこと自体が

悪くないのかもしれないですね。

雑多

3Dプリンタぽちった。あとは3Dスキャナだな。

 

仕事の量が概ね1.5～2倍になった。

4人でやってた作業を一人退職、一人は別プロジェクトメインになってほぼ仕事せず。

そのため仕事の自動化レベルが一つ上がって、応用するとGoogle Apps Scriptに仕込んで事務処理がかなり自動化できそうな予感がしてきてます。

 

現状Outlookの予定表の設定したアラームがなったら本文テンプレ＋指定宛先＋日付等々はOSの時計引っ張って内容確認したらメール送信できるような状態の画面を出すマクロを組んでみて

GoogleカレンダーとGmail、Googleドライブ連携でGoogle Apps Scriptで結べば同じことできるんじゃないかなーと思案中です。まだ調べてない。

それらが整備されれば下手な事務作業ほぼカレンダーに予定突っ込んで自動処理して終わるから楽になるなあ。定期的なものはカレンダーの定期アイテムでOKだし。

そのうち何か試作するかもしれません。

 

とりあえず

・3Dプリンタいじる。CAD慣らしが先だけど。

・3Dプリンタ設置のためラック組むのと、余分なゴミの処分

・合間に確定申告。

・さらにその合間にGoogle Apps Script

・見たいDVDを見終わってない

 

いつ終わるんだこれ。

日記を移行しました

あんまり内容書いてないですが。

 

Facebookのつぶやきに色々流してたんだけど、流れてしまってLoggingできないため

結局ブログにすることにします。

Twritterは元々アカウントだけでやってないし。

 

短文を垂れ流すより、ある程度思考を纏めて出すブログ形式の方が合っているのと

コメントはともかくイイネとかあまり価値を見いだせないので…。

# リア充アピールが面倒くさいというは否定しない。

 

というわけでボチボチやっていきます、多分。

 

生産技術は難しい

ただの戯言。


去年末からずっとデバイス周りをいじりながら、どうやったら上手く行くかって色々試行したり思考したりしてるわけだけども、2月終わりくらいから破綻しております。


その原因というか無知の賜物なのですが、デバイスは設計して試作してから
量産に入るまでに「先行量産」とか「試作量産」ってフェーズがあるらしいのです。
これを完全に抜け落としていて、作業計画が見事に吹き飛びました。


ソフトウェアって実質量産が要らない。いくらでもコピーできるんだもの。


でもデバイスは試作機をベースにして、安定して量産が行えることを確認し、必要に応じて修正が必要になる。
主には品質を落とさず且つ少ない手間で作れるように製造工程を最適化すること。
これがどうやら「生産技術」というものらしい。


ソフトウェアで言えば、頻繁に変更が発生する箇所はアプリケーションから切り離して
Configにするとかそういう話なのだけど
生産技術ではそれがコストに直結するので、ソフトウェアのそれとは比較にならないくらいの厳密さが必要っぽい。


概念とか目的辺りはソフトウェア開発のそれとあんまり変わらないのだけど
イマイチ勝手がわからないというのが正直なところです。


とりあえず当初計画で積んでおいたリスク分の余裕が完全に吹き飛んでいるので
作業関係は前進させつつも、計画面は仕切りなおしにしようと思います。


というわけで、色々手配して散財モードへ。

スクリプト言語Perlが萎んだ？

http://anond.hatelabo.jp/20130307004741

結論

2005年までのPerlはまさに我が世の春を謳歌していたが今や目も当てられない惨状でプログラミング言語のシーラーカンス・COBOLとすら比較され出す始末。昔Perlの人として売り出していたハッカーも、いつのまにかPythonの人になっているケースも海外では多い。10年でここまで時代は変わる。今のメインテクノロジーも明日は我が身だ。小手先の技術に乗っかってモダンだのハッカーだの聞こえのいい言葉を汚い口でまき散らして消えて行ったPerlエンジニア達の死を無駄にしてはいけない。変化の速い時代に生きる我々に必要なのは本質を学ぶ事だ。コードの書き方とかどうでもいいんだ。もっと10年20年たっても色あせない情報工学を身につけなければならない。

CPANで無管理になってるモジュールがあるなあ、とは思うけど
Perlがシーラカンスだとは決して思わないです。


COBOLが急速に縮小したのは言語の問題というよりも、それを扱っている人達が
「どのようにそれらのプログラムが書かれているか？」をドキュメント化せず、牢名主化しているのを叩いて追い出すスケープゴートになった不遇の言語だと思っています。


むしろ今組んでいる画面回りを何の言語で書くか？と考えた時に
使い手が多そうだからという理由でPHPを選びましたが、Perlは選択肢の一つに入れていました。



時代だのテクノロジーだの情報工学だの、存在しているようで漠然としていてどうとでも捉えられるような言葉並べ立ててDisられるほどPerlは錆び付いていないと思いますよ、個人的に。


言語単位でオワコンだのなんだの叫ぶ前に
変数関数参照クラス定義くらいは似た系統の言語で使えるようになる幅広さとか
どの系統の処理が内部でどのように処理されるから、CPUやメモリのリソースをどの程度食うだとかの深さとか
マルチプロセスやマルチスレッドだのの同期・非同期を絡めた並走処理を上手く回すための複雑さとかを
身に付けるのが良いのではないかと。


こういうのが言語に基づかない本質的な技術力ってやつじゃないですかね。

自動在席管理システム 更新

http://kyou1207.sakura.ne.jp/eyetell/
自動在席管理システム EYETELL α版 Ver.20130213


完全自動で設置場所に人が居るかどうかを判別し、表示するシステムです。


現在の設置場所：自宅自席前、及びその付近。




●機能更新

  1. 表示を見やすくしました。
  2. データの最終更新日時を表示するようにしました。
  3. 画面を開いている間自動更新するようにしました。
  4. 項目が4行に増えました。試験運用のための変更です。
  5. その他内部処理を幾つか自動化しました。



●その他更新

  1. 名称をEYETELLとしました。二転三転した結果なのでまた変えるかもしれません。