SSH Keyを作成してGitHubなどに接続してみる - Qiita

大事なことなので。

SSH Keyを作成してGitHubなどに接続してみる - Qiita: GitHubやGitLab上のリポジトリへgitコマンドでファイルをpushする時に、上手く接続出来なかったのでSSH Keyの作成からやり直してみました。これはその作業ログなので自分用忘備録です。 [参考資料] Connectin...

OneDriveをUbuntuで（20.04 LTS）

 備忘録

• 本家
  Github　　　
  abraunegg / onedrive
  https://github.com/abraunegg/onedrive
   
• 参考
  blog.PanicBlanket.com
  https://blog.panicblanket.com/archives/5391

 

実行中の状況確認

 onedrive --monitor

 

 

 

 

 

 

 

        

     同期中の状況が見える。

 

Test

ちょっとしたテスト。

https://play.google.com/store/apps/details?id=co.vero.app

文字だけの投稿が今のところできないけど、考え方を変えて、文章の投稿はBlogでしてそれを共有するって事ではどうだろう？

設計書ってさ。

ある職場で、設計書書いてた時の話。
レビュー時の指摘事項で。
・処理の階層が深すぎるから、そうならない様にして。
・サブ処理として書かれると、判りづらいから、そうならない様にして。

で、思ったのが…
「…それ、相反してなくない？」

フラットに書いたら、深くならざるを得ないと思うし、自分としてはそうならない様に…と思って、サブ処理の記述にしたんだけど。

で、既に有る設計書見てみたらば、
・処理のブロックは罫線引いて区別する。
　（当然、ネストもそれで表現）
・結果として、「項番が深くならない」。
という事だったんだけど。

（深くしないのは、項番であって処理ではないって言うね (^_^;)）

ただ、詳細設計書として考えた時に、これをそのままコード化なんてしないから（したら、読み辛くってしょうがない）、サブ処理に分けるんだけど、そうなったら、設計書とコードの乖離が発生しないかな…と。

個人的には、もうこう言うドキュメント（設計書）は書かない方向で良いんじゃないかと思ってる。
勿論、「するべき事」を書いたドキュメントは必要では有るけれど、コードと１：１になる様に記述する設計書は無くてもいいと思う。
改修しても、コードだけ修正してドキュメントなんてメンテしないだろうし。

例えば、バグが出て改修しても、改修後のテストはしても、改修に先立ってドキュメント修正→レビュー→改修なんて手順踏んでるところって（自分が見た限り）無いと思う。（個人的にやってた事は有る）
ドキュメント大事。と言うなら、本来そう言う手順を踏むべきだとは思うんだけどね。

あと、ドキュメントのフォーマットもね。会社毎とか、ベンダ毎に違うのも……どうにかならんのかな。
あんなに「業界標準」が好きな業界なのに、こういう所を標準作らないってのもね。

結局、大手がメインフレームやってた頃のやり方をそのままSAPに持ってきてるから、そんな事になってるんよね。

むぅ。どーーにかならんもんかな。

Spotify Discovered Weekly

自宅にいる時に音楽聴くのは、殆どSpotifyなんだけど、 "Discovered Weekly"が一々ツボを押さえていて楽しくてしょうがない。

"Discovered Weekly"ってのは、今まで聴いた曲の傾向から勝手にPlaylistを作ってくれるんだけど、知ってるバンドやミュージシャン以外も選曲されていて
「あ、こんなのも聴いてたな」
なんて発見も有ったりしてる。

どちらかと言えば、80,90年代のRockが中心でボカロ曲出て来てないけど、恐らくそれは、Spotify自身にそのジャンルがラインナップされて無いからじゃないかとおもう。

どちらにしても、週末。どんな曲やバンドが有るのかちょっと期待してSpotifyを開けている。

やっばり、無駄な気がしてきた。

通勤にかかる時間と費用。

社員に定期代支給するより、通信インフラ調えてテレワークさせた方が人件費は抑えられると思うんだがな。

なんか最近、客先常駐って作業形態自体が無駄な気がしてきた。

極論すれば「予定通り、予定された品質のもの」が納品出来れば誰も困らん訳で。

恐らくそれが解っているにも関わらず、踏み切れないのは、





単に面倒臭いだけ

何じゃないかと思ってみたり。

SAPでの開発って…

SAPの開発の仕事をずっとしていて、今更ながらに感じるのは、

「今の大半の企業のSAPの使い方は間違っているんじゃないか？」

と言う事。

殆どの企業は、自社の業務にSAPを合わせ様としていて、だからアドオンが多かったりしている。

でも、本来のSAP(ERP)って言うのは、「業務改善」のはず。

その為に、SAPではベストプラクティスとテンプレートが有るのだけど、ベストプラクティスを導入していても、それに合わせての改善をしているところを見た事が無い。

業務ヒアリングしてFIT&Gapをする。とは言っても、「Gapが有るのはシステム。だからFitさせる為にアドオン」と言う方向性ばかりではないんだろうか。

それでいて、作ったアドオンの改修にはスピードを求めてアドホックな改修を入れるからメンテナンスし辛い物ばかり出来て来る。

system構築するのに、時間と金を掛けたく無ければ、systemに合わせる為の業務改善をするべきだと、最近思ってる。

Posted via Blogaway