投稿

575判定API(雑)を作った

イメージ
タイトルママ 週末のLTLovers第1回に向けたLT駆動開発を行った。 したことmecabのインストールcabochaのインストール試行&実装出来てしまった 実装時間は3時間位だった。まぁほとんどmecab/cabochaがやってくれることをそのまま食っただけなので大したことは全くやってない
ソースこちら
感想/知見難しい漢字を読ませるには辞書に手を入れる必要がある(と思ってる)ので今回はパスカタカナ語は読みが入らないっぽいので別途判定したcloud9にで環境を作ってみたがCRF++をインストールしたあとはldconfigを実行する必要があったのが抜けていて少しハマったfireballというWAFを今回使ってみたが、まぁまぁよさそうかと思ったが400をわたしてるのに500が返っていてこれはちょっと調べないといけないなと思った。 そんな感じ デモはLTLoverで。お楽しみに。

https://ltlovers.connpass.com/event/60152/

goのlog系パッケージ標準エラー吐きがち説

goのロギングパッケージはstderrがお好き 早めに出社したらちょっとハマったので調べた TL;DR fmt.Println()はstdoutに吐くのにlog.Println()はstderrに吐くから気をつけようね。
世の中には2種類の標準出力しかいねえ()標準出力(stdout)標準エラー出力(stderr) あれ、log.Println()がerror出力に吐いてるぞ?と思った我々取材班はアマゾンに飛んだlog.Printlnのソース func Println(v ...interface{}) { std.Output(2, fmt.Sprintln(v...)) }
stdってなんやねん・・・とソースを上にスクロールするといた

var std = New(os.Stderr, "", LstdFlags) お前標準エラー出力やないか!!!!

Overviewにも書いてあるからぐうの音も出ない
Package log implements a simple logging package. It defines a type, Logger, with methods for formatting output. It also has a predefined 'standard' Logger accessible through helper functions Print[f|ln], Fatal[f|ln], and Panic[f|ln], which are easier to use than creating a Logger manually. That logger writes to standard error and prints the date and time of each logged message. Every log message is output on a separate line: if the message being printed does not end in a newline, the logger will add one. The Fatal functions call os.Exit(1) after writing the log messa…

Suddenly IntelliSense on VisualStudioCode shows only PANIC When code with golang.

It's Really Suddenly I love to use VisualStudioCode when code with golang. but after updated to golang 1.8, vsc's intellisense(or code hinting?) suggests only "PANIC" suddenly.
but it was a known problem.
i found this issue right now. and wake my iterm up, typed gocode close and
go get -u github.com/nsf/gocode (this just in case)

and now, all things fixed clearly and made my coding great again.
appreciated all internet thing. thank you.

理解してほしいこと、教えないでほしいこと

なんでこんなことを書くか 問題解決とその手法について、結構勘違いしている人が多いなと今まで何度も思ったし、これからも思うんだろうなと思ったので、間違っているかどうかは知らないがとにかく書き起こしてみることにした。割りとふわっとしたのでそもそもちゃんと伝わるかどうかもわかりません。

とにかく、世の中には情報が反乱していて、エンジニアによる問題解決にも様々な手法が交錯し存在していて、ただそういった手法のみを入り口にして問題解決が成立できると勘違いしている人も多いな、と思っていて、用語ばかり飛び交ったり、用語をただの知識マウントに使ったり、色々とインターネットはやはり地獄だなとなるようなことがたくさんある。そういった地獄の中で、それでも何か伝えたいことをこの駄文から掴んでもらえると嬉しいのだけれど、駄文を書き連ねているだけなのでそれも難しいかもしれない。
TL;DR まず、仕事をする上では物事の本質を常に把握するように務めるべきである。
また、人に相談して得た手法は役に立たないし、他人が自分のために常に正しい答えを用意してくれると思っているとしたらそれは幻想であり、あなたが他人のために常に正しい答えを用意できると考えているとしたら、それは妄想である。
少なくとも理解してほしい、と思っていること 「問題解決」の手法でなく本質を捉えて欲しい 優秀なプレーヤーは、まず問題解決そのものの本質を理解していて、それから開発手法であったり、設計技法であったり、開発戦略であるところの方法論を議論し、また積極的に用いているように思います。ときには彼ら優秀な人々が、特定の手法を用いることでその本質を意識せずに問題解決を為しているように見えることもあるかもしれませんが、それは幻想です。彼らが手法を上手く使いこなしているのは、問題解決の根本的な部分、つまり地道なコミュニケーションとトライ(アル)アンドエラーを繰り返してきた経験からなるものであって、手法を先行させることは基本的には出来ないのです。
おそらくその本質自体も、プレーヤーによって経験してきた難しい問題が異なると思いますし、当人にフィットする勘所のようなものはそれぞれ異なっていることでしょう、それがベースになっている上で手法が成り立っているので、それを上辺だけ真似して問題を解決することは出来ない、そういう風に私は思っています。
これは…

雑兵MeetUpのCloseと新たなコミュニティ作成のお知らせ

雑兵MeetUpをCloseしたお知らせ 2015年10月から、たくさんの方にLTしていただいた雑兵MeetUpでしたが、2/24(金)に開催した雑兵MeetUp #9 〜転職MeetUp 2nd GIG〜をもちましてCloseと相成りました。会場を貸して頂いていた21cafedots.のみなさん、参加していただいたすべての皆さん、本当にありがとうございました。
Closeした理由としては、

実際来てくれて喋ってくれる人って「雑兵」と呼ばれるたぐいの人じゃないよね、と言われることが多くなってきた事実。そうなるとより一層そういう傾向が増して、すごくない人達の成長を期待した会なのだけどターゲット層の人たちが来づらくなってるのではという感想。そもそも本当にすごくない人たちは、「喋ってみよう」どころか、「勉強会に行ってみよう」というマインドにならないという感覚。 というようなことが幾つか重なったことが上げられます。いわゆる「初心者勉強会初心者集まらないよね?」アンチパターンですね。妖怪不祥事案件とも言うかもしれません。もうちょっとなんとか出来たのかもしれませんが、多分コンセプトを変更する必要があるのだなということを強く感じたことが今回のCloseに関しては強いです。
そして新たなLTコミュニティを作成しました まだ実際に最初のイベントを直近で行うわけではありませんが、上記を踏まえて新しいLTコミュニティを作成しました。
LightningTalkLovers
このコミュニティでは以下を解決したいと思っています。 普段LTとかしない・LTとかしたこと無いんだけど何か喋りたい気持ちをどうにかしたいLTチョットデキルんだけど、たまにはしっかり準備する必要がない感じで喋りたい・ちょっと気になることがあるからLTついでに議論してみたいという気持ち 要するに「喋ること」にフォーカスして、(自称)すごい人だろうと(自称)すごくない人だろうと、何か喋りたい事がある人が集まって楽しくおしゃべりしながらキャッキャウフフすれば良いんじゃないですかね!作りますね!!!という気持ちです。
例によってテーマを一つに絞らないことで、いろんな話が聞ける場所と言うかたちを取りたいと思っています。
現時点でイベント予定はなく、今のところ 集客どういうふうに考えていこうかSlackを作ったけれどどう運用していく…

エンジニアの妻になってしまった我が妻には感謝している

この記事は妻・夫を愛してるITエンジニア Advent Calendar 2016の21日目です。

前日はtamootさんでした。

はじめに
パートナーを愛してる話ということですが、圧倒的感謝しかないです。死ぬ。感謝で死ぬ。ほんとに。

昨今のインターネッツは生きづらいので、本当は3倍量くらい書いてましたがシンプルな感謝状になりました。インターネット滅びろ。
感謝
そんなインターネットで出会い、それからお付き合いしたのが日韓ワールドカップ後くらいからなのでもう14年のおつきあいになりますか。出会った当初はお互い学生でしたし、今のような職業に就くとは思ってませんでしたね。
働き始めてからの二人の夕食については、基本的に僕が作るスタンスで生活してきました。これは妻が偏食であること、また食に対してもともとはあまり能動的でないことなどから生まれたスタイルで、かつてマウントレーニアのカフェラテを夕食と言い張り、キャベツしかまともに食べられる野菜がなかった妻が今ではある程度サラダやトマトソースなども口にできるようになったことを考えると大いなる進歩を感じます。これは逆に感謝されたい。されたい。してくれ!!!
とはいえ、いくぶんかの家事をこちらで引き取ってはいても、なにぶん僕が仕事でコード書くのに熱中したりしてて夜遅めの生活になっていて、妻には日々の生活において主に子供関連で負荷がかかっていて申し訳ないなぁと思っています。いつも苦労をかけています。ごめんなさい。本当にありがとう。

いつも夫婦ふたりともおふざけ野郎なので、とりとめなく延々とふざけているのですが、このやり取りに本当に癒やされています。最近は子供が輪をかけてふざけ野郎なので、その点は割りと心配していますが、避けられない運命ではあるので、彼がふざけを極めたければ極めれば良いなと思っていますし、それを二人で見守ることができれば最高ですね。僕だけかもしれませんが。
最後に
スイート10は難しいかと思いますが、来年も何度かネックレスをプレゼントできるようにがんばりますのでご容赦ください。温泉旅行にでも行きたいですね。ありがとう。

明日はsakanatechさんです。楽しみですね。

2016年にgoを使ったのでまとめ

あ、怖いな怖いな、穴埋めたいなーと思っていたのでつらつら書いて埋めたいと思います。

はじめに
この記事はGo Advent Calendar 2016の10日目であるべき投稿だったようです。

2015年からgoやりたいなーと思っていましたが、今年の4月に転職してから思いがけずgoでWebAPIなどを書く仕事を色々やらせていただけたので、良かったもの/こと、仕事をする上で自分でつくったもの、などについて書きます。


良かったもの
仕事で作ったものはWebのAPIだったり社内の他のシステムにキューイングするライブラリだったりと、そんな小難しいものは作っていないので箇条書きに
goaginkgogo-bindatazgok この辺のライブラリやWAFには非常に助けられました。最初はgojiを利用して、それをechoでまるっと書き直したりしていたのですが、ドキュメントを書くのが面倒なのがきっかけで今年後半に新しいものを作るときはgoaを利用してみて、非常に良かったです。最初にDSLで設計を書くのが大変ですが、慣れれば設計の楽しさみたいなものも感じられる良いフレームワークではないかと思います。
テストは最初conveyを使っていましたが、もうちょっとSpecに近いテスト記述をしたかったので途中からはginkgoに切り替えています。Ωは使わずに、Expectで書いています。conveyはブラウザでテストがグルグル回るので楽しいです。自動でぶん回してほしい人はconvey使ってみてください。
最後のgo-bindataとzgokは両方共静的ファイルをバイナリに含めるためのライブラリで、少しアプローチが違います。
go-bindata → 静的ファイル群を.goのファイルに変換するzgok → ビルド後のバイナリに静的ファイル群をZIPアーカイブとして追加する go-bindataだと変換後のファイルをcommit資材に入れるかどうか迷ったりして、ちょっと迷ったりするのですが、テスト用のファイルだけcommitしておいてその後はビルド直前に再度変換をかけたりするようにjenkinsなどでシェルを書くことで対応しています。 ビルド前後に何か書く前提であれば、zgokのほうがcommitとしては悩まなくて良いので個人的には好みです。

自分で作ったもの
github.com/deadcheat…