SystemC] すごいSystemC エロく学ぼう!(part1)

本日、SystemC Japan 2014ですね。

さてさて、概念として定着した「#ひらっちエロい」筆者のもと
監修「ひらっち」の裏SystemC Japan 2014の資料が届きました。

必見です!!!

ひらっちの裏の顔が・・・(゚д゚)!

beep on(音) Vim Script

ご注文はおすしですか? #kernelvm

のスライドを見ていたら、beepってソースコード公開しているのか。
しかも、実際見てみたらかなりシンプル。

これはイケそう!

っと思って、自分のEvernoteにメモ

Vimネタ:+beep音(Vim scriptで作曲)

本気でやる気あるのか自分でも分からないけど
とりあえず、メモ

Vim Advent Calendarで見つめなおす .vimrc

本記事は、Vim Advent Calendar 2013の 169日目の記事になります。

168日目は @rksz さんの「Vimの生産性を一撃で高めるシンプルなテクニック」でした。

今年初めての Vim Advent Calendarの参加です。
参加したいと思いながらもこんなに遅くなってしまいました。

Vim Advent Calendar 2012 から
非常に有益な情報が詰まったカレンダー。本当にすごい(かなり)

今回、VAC2013からお世話になっている記事(プラグインなど)を紹介したいと思います。

fugitive.vim 便利!

vim-quickhl とか使ってます! 素敵!

かなり良いっす!

gR

知らなかったです><

ようやく使おうとしてトライしているところ。なう。
たぶん、「snowdrop#include_paths」のところって以下の感じがする。(確信なし)

let g:snowdrop#include_paths = {
\   "cpp" : [
\       "C:/MinGW/lib/gcc/mingw32/4.6.2/include",
\       "C:/cpp/boost",
\       "C:/cpp/sprout",
\   ]
\}

indentLine使ってます!

交互に開きたかっったんです!!!

もうっ/// テキストオブジェクト中心です!

vim-textobj-blockwise も良い感じっす!

(実は gf で開かないために、開くように編集していたなんて言えない)

なんてこったい!
してしまっていた!!!

おわり

ちょっと書きだしただけでもいっぱい参考になってます。
自分ももっとがんばりたい。

ビムッ!!!ビムッ!!!

明日は・・・
あれっ???

行末に文字列を挿入する

ふと。分からなくて同僚に聞いてしまったので、そのメモ。

  reg a
  reg [12:0] b
  bit c

とか言う時に、

  reg a;
  reg [12:0] b;
  bit c;

というように行末に「;」を挿入したい場合があって、
そのやり方について、方法は2つ。

置換する

同僚に教えてもらった方法がこれ。

:'<,'>s/$/;/

上記はノーマルモードで「Shift-v」など範囲指定している時とか。
「$」は確かに 行末を示すなぁ〜と思って思わず関心してしまった。

挿入モード

とかにあるように、「矩形選択後」に

$A

ですね。確かに。 これ、ノーマルモードの時に、「A」とかで出来たらいいのに。

消費税 8%を実感した

4月1日より消費税が 8%になるのは知ってた。
むしろ、必要なものとかは買ってたりしてた。

でも、そんなに変わらんだろうって内心思ってて どうでもいいかなーっていう気持ちだった。

3月末から家族のインフルでゴタゴタしていたので、 実際に外に外出したのは昨日の4月4日だった。

そこで、消費税を実感してしまった。。。

嫁さんからのおつかい。
会社の帰りにセブンイレブンにより、シュークリームとカフェオーレを購入。

そこに記載されていたのが、100円(税込み108円)

「えっ!? 108円」...そうか... 8%だった...

105円108円 これほど差があるとは思わなかった。。。

思わず。。

澪(みお) 飲んだ

スパークリング清酒 というものを初めて飲んだけど、
ジュースみたいで美味しかった。

f:id:KSuzukiii:20140128223656j:plain

ツールに使われる人々

開発工数の短縮を目指して、新規ツール/手法を導入する。

そういって始まった開発において、どのような問題が起きたか。

エバンジェリストの働き方

新規ツールを導入する前には必ず、評価期間が設けられる。
また、3~5年という経験と実績もあるはずだった。。。

頼らない/受け身なサポート

開発プロジェクト側は今回初めての人が多数。
プロジェクト側で、評価(トライアル)を行いベンダーと共に行ってきた。
しかし、評価メンバーだけで開発するわけではない。
評価メンバーはごく一部...
全体メンバーの1割かもしれない。

そうした中で

エバンジェリストなるサポートにアドバイスをもらっているか?

この答えは「No」あるいは後述するサポートの問題かもしれない。
マネージャーがどうあるべきかをわかっていない開発が始まってしました。
分からないことが分からない」っといった名言がうまれる。

さて、「分からないことが分からない」にて対してサポートが行うことは、

なにもしない」 「聞かれたら答える

腹立たしいことに。。。
これが現状か。
「なにもしない」理由は簡単だった。

プロジェクトに入ることになるから

サポート*1とは

支持(する)、支援(する)、援助(する)、補助(する)、扶養(する)、支持者、後援者、などの意味を持つ英単語。

開発フローに支援しなかったプロジェクトは今、燃えている。。。
一つの要因としては、従来手法で行っていた作業工程を無いものにしてしまったから。
これで、作りたいものが作れるのか。。。
サポート、エバンジェリストとはいったい・・・

ツールのバグ取り開発

開発プロジェクトでは、初めての人が多数。
しかも、作業工程が疎かになった。
そうした中で発生した開発名にふさわしいだろう。

ツールのバグ取り開発

適当に作られたものに対してツールを使う。
雑なものに対してのツールの応答はこんな感じ。

  • ツール実行時間の増加
  • ツールのバグ発見 などなど

つまり、ツールのデバッグを行っている ようなものである。
そこで、プロジェクト側の判断は

ツールが使えない

という結論。

しかし、私はそうでは無いと思っている。
雑な」なものを改善するべきだと。
プロジェクトが遅延する理由が「ツールが悪い」では話にならない。
それはエンジニアの仕事といえるのだろうか?

これから

無くした作業工程は行わなればいけない作業だった!!!
そして、今からでも間に合う!
そう思うからこそ動いているのに思いは届かない。。。
新たに人だけが追加されていく。

あぁー 無常(´・ω・`)