トップ «前月 最新 翌月» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|

ToDo:


2018-08-04

_ PFN

最初の3日の感想

  • 想像してたよりは普通に会社だなあという感じ。あまり大きな不満がない
  • 仕事はしばらくはすごく楽しそう。まあプロジェクト変えた場合でもそうなるし、これは別の会社にしててもそうだったかなと思う
  • 日本語がほとんどなのは、すごく楽…

(18:39)


2018-08-05

_ 英語

識別子とかまで日本語?と聞かれて。観測範囲では

  • 識別子は全部英語
  • コメントは入ったチームは英語。まあそもそもコメント少なめ感
  • コミットメッセージもチームは英語、別のとこは日本語の人がいたなぁ
  • レビューはうちは全部英語、そもそもやってないチームもある
  • ドキュメントは日本語が多い感じ
  • 重要な手続きとかは日英両方みたいな書き足しを頑張ってるぽい
  • TGIF的な会合は英語
  • チャットがおおむね日本語たまに英語
  • 口頭もほとんど日本語だけど、なんかたまに英語を聞く

くらい

(00:00)


2018-08-07

_ NiZ

リアルフォースとかHHK的なやつを作ってる会社らしい。最近の中国はいろんなものを、安く、同じ品質で、カスタマイズ性を高めて、売るなあという感じ

でこれを買ったけどなかなか良さそう

https://www.amazon.co.jp/dp/B075XM7R3W/

レビューにもあるけどリアルフォースとは結構反応は違う。どっちがいいということはよくわからないけど、 NiZ の方が軽い。 NiZ の方があうかもしれない。

カスタマイズ性は、バネを入れれば重さを変えられる、というのと、キーボード側にある(!)ソフトウェアを Windows アプリからいじることによって、キー配置とかを変えられるらしい。ただ Windows 環境がなくてこれは試せてない…

(09:04)


2018-08-17

_ kati

もう owner じゃないわけだけど、なんか最近来てた PR が面白い

https://github.com/google/kati/pull/141

GNU make は変数が基本グローバルで色々バグりやすいんだけど、予期してなかった再代入は一つ困りがちなものとしてある。 CXX みたいな変数をトップレベルで定義してたとして、別の Makefile を include したら中で CXX を定義してて上書きされちゃう…みたいな。というわけで kati には

.KATI_READONLY := CXX

とかすると CXX が readonly になる、ってオリジナル特殊変数が導入されていた。これは GNU make の流儀 (.PHONY とかに似てる) にもそってて、 kati で valid なら GNU make で valid であり (GNU make 的には、 .KATI_READONLY への代入は単に無駄な代入)、良いものだったと思う。

でもこの PR は .KATI_READONLY をもっと手軽に作りたいというものらしく、その syntax は

CXX =$=g++

とかいうもの。 $= は普通値が入ってないため、 GNU make でも同じ動きをする、というのは保たれる……んだけど、 =$= の後に空白を入れることは許されていないし、あんまりじゃないかこれって感がある。もうちょっといい syntax 無いものかなあ?

(23:09)


2018-08-29

_ かいしゃ グッドプラクティス

おおむね快適に過ごしてる。普通に粛々とコード書いてる感じなので楽しい

最近少し考えることに、どのくらい前職で良かったぽかったこととかを言うか、みたいなのがある。元々あまりプロセス的なやつ、つまりバグ管理とか、プログラムのコメントとか、コーディングスタイルとか、強い意見がほとんどない。だからプロジェクト変わった時なんかも、新しいところに適当にあわせて生きてると思う

なんかでも、Xはどうしたものか、みたいな会話が行なわれてて、そういえば前職ではXはこういうルールだったなあ、とか思うと、そういう話を紹介したくもなる。ただなんか、その手のルール、そもそも僕は元々好きでなかったもの、正しいかもしれないけど過剰で煩雑だったもの、前職の規模では有用でも他に適用できないもの、実際他でも有用なもの、などあって、はてさてという

あとなんか、有用なプロセスでも人に押しつけられたらイヤじゃない?という話もあると思う。 WebKit でグーグルとアップルが仲良くなかったの、すごく印象的だったんだけど、あれ多分にグーグルの人が「WebKit のこのプロセスはダメだー。グーグルではこうやっているー。このツールを使えー」みたいなことやってたからじゃないかと思ってる。実際、 gyp ゴリ押ししてる時とか、「いいものなんかしらんけど、グーグルがゴリ押ししてる時点で萎えますわ」みたいなこと普通に公言してる人がいたような記憶がある。ここで問題なのは gyp いいものじゃないこともあると思うが(まあでもファイル増やすたびに6つくらいのビルドシステムのファイルいじるよりは当然良い)

そんなこんな。あまり https://twitter.com/imos/status/980764006876028929 みたいに布教するぞ!という気分にはなれないなぁ。しかし何も言わないのもどうかとも思うし、加減がよくわからんな?という感じ

(09:24)

本日のツッコミ(全2件) [ツッコミを入れる]

_ morrita [一通り結果をだしてからにする、くらいだと説得力あるげ。 WK の例だと abarth がいうのとボンクラがいうので..]

_ shinh [あーありそうですねえ。意見は発言者じゃなく内容で判断されるべき、みたいなのはなかなか守られない理想ですね。。]


2018-08-31

_ 345c 7140cpp 2795py

(20:45)


2018年
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
1.shinh(2018-08-31 18:55) 2.morrita(2018-08-30 01:21)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h