気のせいだろうか、キーボードの事ばっかりツイートしてるような気がする今日この頃です。
ErgoDashを作りました
60%キーボードを探していて、候補としては
- Fotitude60
- Lily58
- Iris
- Viterbi
- ergoinu
などを考えていたようです。
気のせいだろうか、キーボードの事ばっかりツイートしてるような気がする今日この頃です。
60%キーボードを探していて、候補としては
などを考えていたようです。
jjug ccc 2019 springに行ってきました。
http://www.java-users.jp/ccc2019spring/#/
ちょっと私用があり、午前から夕方ぐらいまでの参加でしたが、楽しませてもらいました。
goconも行きたかったし、なんならInside Frontendというイベントも気になりましたが
なんだかんだjjug cccに参加しました。
(日程被っていなくて、抽選漏れとかで無ければそれぞれ参加したかったですね)
yujisoftwareさん、いつも助かります
https://yujisoftware.hatenablog.com/entry/2019/05/19/040112
以前から自作キーボードが界隈で流行っているのは目にしていました。
興味もあったが、市販のキーボードで我慢していたところがあります。
今、Kinesis Freestyle2 Keyboard(たまにHHKB Lite2)を使っています。
いわゆる市販のキーボード?です。
さて、Java is still freeなわけですが
https://medium.com/@javachampions/java-is-still-free-2-0-0-6b9aa8d6d244
https://www.sakatakoichi.com/entry/javaisstillfree
どのJDKをどのバージョンで使うかねぇという話がありますよね。
JDK 8を使い続けるという選択肢もあります。
いろんなベンダーがLTS(long term support)としているJDK 11を使うということも出来ます。
色々考えてみましょう。
FINAL NOTICE: Two days left to upgrade your CircleCI configuration by March 15 This is the final notice reminding you that one or more of your projects has recently used the CircleCI 1.0 infrastructure, which will no longer be available after March 15, 2019. In order to address this issue and keep your project(s) building, please see: Instructions on seeing which projects still use CircleCI 1.0 config A guide to migrating from 1.0 to 2.0 CircleCI 1.0 EOL policy In two days, all projects will require a circle/config.yml, the 2.0 configuration file type, to build on CircleCI. It’s possible that your project is currently missing a configuration file, and is building on CircleCI 1.0 by default. We know we have sent you a number of notifications in recent weeks regarding 1.0 EOL. At the risk of over-informing you, our goal is to make sure that zero teams or projects are caught unawares when they can no longer build on CircleCI 1.0 on March 15, 2019. We are here to help in making this switch, please visit the migration center. Thanks again, The team at CircleCI
こんなメールが来ていたわけで。超めんどいな、と思ってスルーしていたんですが、
まぁ書き直すかぁということでやってみました。
何を今更という人もいると思うのだけど。
varは書く必要ないな、と改めて思いまして。
ということで自分の整理も兼ねて書いています。
小ネタですが。
ansistorano.deployとansistorano.rollbackがrenameされたらしい。
今年もまた1年が終わってしまった。
諸行無常。
自分の中の恒例行事となっているので、
振り返りと来年の目標をユルく立てようと思います。
今年の目標はこんな感じ(だったよう)でした。
これらを振り返っていく。
・・・・・・・。
今回、EEサーバーを使う方を考える。
8が最新の、はず
は無論okとして、
がちゃんと動くかどうか。
EE7 、 EE8サポート。
Java SE 11もクラスパスモードでサポートしているらしい。
http://wildfly.org/news/2018/12/13/WildFly15-Final-Released/
EE8はサポートしているとして、Java SE 11は issueが上がっている。
Java 9以降は現在サポートしていない。Jakarta EE自体が11対応というかjigsaw対応必要だろう、みたいなコメントが書いてある。
https://github.com/payara/Payara/issues/3382
https://github.com/payara/Payara/issues/2296
蓮沼さんの記事が詳しいが、Java SE 11はサポートしてない。
まぁ、Payaraもまだだし。
https://www.coppermine.jp/note/2018/12/nightmare-of-jep320/
読んでる本を並べてみると、なんかやってる風を装える気がしたので書いてみた。
意外と長めの文章ができ、装いとしては良いかもしれない。
あたりを今更読んでいる。
本を読んでいていつも思うが、
本を読み切るというのが得意ではない気がしている。
というか本を読むのに費やす時間が単純に不足してるだけともいう。
良い本。いろんな人が褒めているので今更褒めるのも野暮に感じている。読んで考察したりしてる部分もある、かもしれない。
少しプログラマ向けではないが、とても良い内容。この本に関しては分厚くないし9割ぐらい読んだ気がする。
実践vimは読んでいるが、大体知っている内容ではある。tips本なので仕方がないような側面はある。たまに知らないことが載ってるので得をする。
発売当初に買って、流し読み。そしていま読み直しているが多少は理解しやすくなったような気もする。
この本もムック本?で読みやすい分量なので一周なめておきたい。
しかし物理本にしてしまったがゴーファーのパラパラ漫画は楽しい。手軽さを求めるなら電子書籍が良いかも。
おそろしいほどに、スマホに依存している。kindle端末もあり、PCもあるので、そちらで電子書籍なら読むことが出来るのだが、一番手軽という点でスマホになっている。
おそらく、PCに本を入れておいてリファレンス的に使うというのも有効ではないかと最近思っている。
個人的な事情で、勉強するのに充てる時間が減ってきた感じがある。
感覚的に言うと無限にあった時間が有限になっただけ、ではあるので少し出来たスポットの時間を如何に有効活用するかが大事になって来ている(これは以前からもそう)。
自分にとっては、ブログに書き出すことも勉強とか読書とか、そちら方面の思考を整理するのに有効なので続けていきたい。
Clean Coderも読みたいが、ソフトウェア見積と計画的な見積のやつも読みたい。色々と積みすぎていて詰んでいる。
どの本を読むか、読まないか、捨てるかも整理したほうが良いのかもしれない。
なんかコードを書きたい
これをやってみようかと。
A Tour of Versioned Go (vgo)
(Go & Versioning, Part 2)
https://research.swtch.com/vgo-tour
vgoの詳細は以下に委ねる。
Goにおけるバージョン管理の必要性 − vgoについて − by @tenntenn #golang #go https://www.slideshare.net/takuyaueda967/go-vgo-102442203
あぁ、なんかまだバグとかあるかもしれないとのこと。issue立ててとのこと。
You are certain to run into interesting bugs, since vgo is at best only lightly tested right now. To file issues, please use the main Go issue tracker and add the prefix “x/vgo:” to the title. Thanks.
とりあえず、素直にインストールしていきます。
go get -u golang.org/x/vgo
。。。なんだ?
go get -u golang.org/x/vgo go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src; ignoring go.mod; see 'go help modules'
なんかwaring出てるけど、一旦進めてみるか。
helloってディレクトリを作る
$ mkdir hello $ cd hello
main関数書く
package main // import "github.com/you/hello" import ( "fmt" "rsc.io/quote" ) func main() { fmt.Println(quote.Hello()) }
go.modってのを作ってビルドするらしい。
echo >go.mod vgo build
果たしてすんなりビルド通るかな。
なんか、うちのネット環境が貧弱なせいもあって初回ビルドすんごい重いな。
$ vgo build go: finding rsc.io/quote v1.5.2 go: downloading rsc.io/quote v1.5.2 go: finding rsc.io/sampler v1.3.0 go: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c go: downloading rsc.io/sampler v1.3.0 go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c $ ./hello こんにちは世界。
お、なんかすんなりできた。
ディレクトリ構成はこんな感じになった。
tree . ├── go.mod └── hello ├── go.mod ├── go.sum ├── hello └── hello.go
go.modの中身はこうなった。
cat hello/go.mod
module github.com/you/hello
require rsc.io/quote v1.5.2
go.sumの中身はこんな感じ。
cat hello/go.sum golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c h1:qgOY6WgZOaTkIIMiVjBQcw93ERBE4m30iBm00nkL0i8= golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= rsc.io/quote v1.5.2 h1:w5fcysjrx7yqtD/aO+QwRjYZOKnaM9Uh2b40tElTs3Y= rsc.io/quote v1.5.2/go.mod h1:LzX7hefJvL54yjefDEDHNONDjII0t9xZLPXsUe+TKr0= rsc.io/sampler v1.3.0 h1:7uVkIFmeBqHfdjD+gZwtXXI+RODJ2Wc4O7MPEh/QiW4= rsc.io/sampler v1.3.0/go.mod h1:T1hPZKmBbMNahiBKFy5HrXp6adAjACjK9JXDnKaTXpA=
どうやら、バージョンを固定するためのものっぽい。
vgoで管理しているものをupdate日付とか一覧で見るにはこんな感じらしい。
vgo list -m -u
実際にupgradeするにはこのようにする。
vgo get golang.org/x/text vgo: finding golang.org/x/text v0.3.0 vgo: downloading golang.org/x/text v0.3.0
逆にダウングレードする際は、バージョン番号を指定してやると良いみたい。
$ vgo get rsc.io/sampler@v1.2.0
vgo test all でvgoで管理されているモジュールのテストが走るらしい。
vgo test all
結果:
vgo test all ok archive/zip (cached) ok bufio (cached) ok bytes (cached) ok compress/bzip2 (cached) ok compress/flate (cached) ok compress/gzip (cached) ok compress/lzw (cached) ok compress/zlib (cached) ok container/list (cached) ok context (cached) ok crypto (cached) ok crypto/aes (cached) ok crypto/cipher (cached) ok crypto/des (cached) ok crypto/dsa (cached) ok crypto/ecdsa (cached) ok crypto/elliptic (cached) ok crypto/hmac (cached) ? crypto/internal/randutil [no test files] ok crypto/internal/subtle (cached) ok crypto/md5 (cached) ok crypto/rand (cached) ok crypto/rc4 (cached) ok crypto/rsa (cached) ok crypto/sha1 (cached) ok crypto/sha256 (cached) ok crypto/sha512 (cached) ok crypto/subtle (cached) ok crypto/tls (cached) ok crypto/x509 (cached) ? crypto/x509/pkix [no test files] ? encoding [no test files] ok encoding/asn1 (cached) ok encoding/base64 (cached) ok encoding/binary (cached) ok encoding/gob (cached) ok encoding/hex (cached) ok encoding/json (cached) ok encoding/pem (cached) ok encoding/xml (cached) ok errors (cached) ok flag (cached) ok fmt (cached) ? github.com/you/hello [no test files] ok go/ast (cached) ok go/build (cached) ok go/doc (cached) ok go/format (cached) ok go/parser (cached) ok go/printer (cached) ok go/scanner (cached) ok go/token (cached) ? golang.org/x/text/internal/gen [no test files] ok golang.org/x/text/internal/tag (cached) ? golang.org/x/text/internal/testtext [no test files] ok golang.org/x/text/internal/ucd (cached) ok golang.org/x/text/language (cached) ok golang.org/x/text/unicode/cldr (cached) ok golang_org/x/crypto/chacha20poly1305 (cached) ok golang_org/x/crypto/cryptobyte (cached) ? golang_org/x/crypto/cryptobyte/asn1 [no test files] ok golang_org/x/crypto/curve25519 (cached) ok golang_org/x/crypto/internal/chacha20 (cached) ok golang_org/x/crypto/poly1305 (cached) ok golang_org/x/net/dns/dnsmessage (cached) ok golang_org/x/net/http/httpguts (cached) ok golang_org/x/net/http/httpproxy (cached) ok golang_org/x/net/http2/hpack (cached) ok golang_org/x/net/idna (cached) ? golang_org/x/net/internal/nettest [no test files] ok golang_org/x/net/nettest (cached) ok golang_org/x/net/route (cached) ? golang_org/x/text/secure/bidirule [no test files] ok golang_org/x/text/transform (cached) ? golang_org/x/text/unicode/bidi [no test files] ok golang_org/x/text/unicode/norm (cached) ok hash (cached) ok hash/adler32 (cached) ok hash/crc32 (cached) ok hash/crc64 (cached) ok hash/fnv (cached) ok image (cached) ok image/color (cached) ? image/color/palette [no test files] ok image/draw (cached) ok image/gif (cached) ? image/internal/imageutil [no test files] ok image/jpeg (cached) ok image/png (cached) ? internal/bytealg [no test files] ok internal/cpu (cached) ? internal/nettrace [no test files] ok internal/poll (cached) ? internal/race [no test files] ok internal/singleflight (cached) ? internal/syscall/unix [no test files] ? internal/testenv [no test files] ? internal/testlog [no test files] ok internal/trace (cached) ok io (cached) ok io/ioutil (cached) ok log (cached) ok math (cached) ok math/big (cached) ok math/bits (cached) ok math/cmplx (cached) ok math/rand (cached) ok mime (cached) ok mime/multipart (cached) ok mime/quotedprintable (cached) # os/signal.test clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] ok net 477.127s ok net/http (cached) ok net/http/cookiejar (cached) ok net/http/httptest (cached) ok net/http/httptrace (cached) ok net/http/httputil (cached) ok net/http/internal (cached) ok net/internal/socktest (cached) ok net/mail (cached) ok net/textproto (cached) ok net/url (cached) ok os 18.478s ok os/exec (cached) ok os/signal (cached) ? os/signal/internal/pty [no test files] ok os/user (cached) ok path (cached) ok path/filepath (cached) ok reflect (cached) ok regexp (cached) ok regexp/syntax (cached) --- FAIL: TestHello (0.00s) quote_test.go:19: Hello() = "99 bottles of beer on the wall, 99 bottles of beer, ...", want "Hello, world." FAIL FAIL rsc.io/quote 0.008s --- FAIL: TestHello (0.00s) hello_test.go:31: Hello([en-US fr]) = "99 bottles of beer on the wall, 99 bottles of beer, ...", want "Hello, world." hello_test.go:31: Hello([fr en-US]) = "99 bottles of beer on the wall, 99 bottles of beer, ...", want "Bonjour le monde." FAIL FAIL rsc.io/sampler 0.008s ok runtime (cached) ok runtime/debug (cached) ok runtime/internal/atomic (cached) ok runtime/internal/sys (cached) ok runtime/trace (cached) ok sort (cached) ok strconv (cached) ok strings (cached) ok sync (cached) ok sync/atomic (cached) ok syscall (cached) ok testing (cached) ? testing/iotest [no test files] ok testing/quick (cached) ok text/tabwriter (cached) ok text/template (cached) ok text/template/parse (cached) ok time (cached) ok unicode (cached) ok unicode/utf16 (cached) ok unicode/utf8 (cached) ? unsafe [no test files]
あ、失敗してるし。
どうやら、1.99.99だとテストFAILするので、バージョン変更しようっていうサンプルっぽいですね。
流れにしたがって、 vgo get rsc.io/sampler@v1.3.1 すると テストをPASSするようになりました。
特定のバージョンを除外することもできる。
こんな感じで。
echo 'exclude rsc.io/sampler v1.99.99' >>go.mod
go.modの除外は、他のモジュールでは有効にならない。
この場合、hello/go.modにのみ除外が有効で、他のモジュールでhelloモジュールが使われていたとしても exclude ...
は適用されないということみたい。
特定のモジュールを指定して、置き換えができるということらしい。
ローカルにあるソースを参照させるようにしたり
echo 'replace rsc.io/quote v1.5.2 => ../quote' >>go.mod
forkしてきたものを見るようにしたり出来るみたい。
echo 'replace rsc.io/quote v1.5.2 => github.com/you/quote v0.0.0-myfork' >>go.mod
ベンダリングして、GOPATHの通っているところにもっていけば go buildも出来るということらしい。
vgo vendor $ mkdir -p $GOPATH/src/github.com/you $ cp -a . $GOPATH/src/github.com/you/hello $ go build -o vhello github.com/you/hello $ LANG=es ./vhello Puedo comer vidrio, no me hace daño.
先ほどの資料によると(https://www.slideshare.net/takuyaueda967/go-vgo-102442203)、
これが Go 1.12では標準となるということですが、
まぁ、普通に使ってみて使えるっちゃ使えるかもなぁと思います(正直ちょっと触ったぐらいではツラミ分からない)。
いちど、ビルド・デプロイの流れを組んでしまえば (それなりに大変だろうけど)なんとかなりそうな。
でも、depとかgbとかもアクティブなのだろうし、他のツールを使っているならそのまま使っていても良いような。
モジュール単位でのバージョン管理とかvgoの仕組みにメリットがあれば使っていけば良い…のかな?
どれにしたらええんや
— yank shaving (@yy_yank) August 23, 2018
Kotlin ver 1.3-M1が出ました。
See what’s coming in Kotlin 1.3-M1
https://blog.jetbrains.com/kotlin/2018/07/see-whats-coming-in-kotlin-1-3-m1/
毎回アップデートがあるたびに変更内容を眺めてはいるのだけど、
今回は久しぶりに面白いバージョンアップだなあと思いました!
など。
そして今回もshirajiさんみたいにKotlinへコミットしてる日本の方もいて良いですねー。
https://github.com/t-kameyama
多分日本の方?だと思う。
西日本応援プロジェクト 真夏の大LT大会!というイベントがありました。
https://techplay.jp/event/684228
という企画でした。
そーだいさんが、なんかやろうとしてるなーと思ったら
あれよあれよと豪華な発表者が集まって来てて面白そうだし、
まぁ自分のお金も人の役に立つわけだしということで参加しました。
全員LTするには勿体無いぐらいでしたねーー。ホントに。
しかもLT面白いし。
なにより、各々、災害に遭った地域を思う気持ちが根底にあり発表しているというのがなんとなく伝わって来て良かったです。
自分は阪神大震災で被災してるし、
関東の震災もあったし、
地元の方では最近また大きな地震もあったし、
そして今回水害や土砂災害がありました。
(ここに並べていないけど、他にも色々震災とかありましたね)
出来ることはなかなか少ないんですけど、まあお金を送るぐらいはまぁ、
簡単に僕にも出来ることだなぁとか思ったりしてました。
あと、現場の状況をちゃんと受け止めること、というか向き合うこと。
災害があったことを覚えておくことっていうのが、なんとなく自分の中でやらなきゃいけないことな気がして、そういう意味でも勉強になる会でした。
なんか妙に真面目な話になってしまったので、このエントリは終わりにします!
2018/06/27にJetBraninsのhadiさんがくるって言うことで、
Kotlin Developers Meetupに行って来ました!
Kotlin Developers Meetup
https://kotlin.connpass.com/event/90679/
準備は@satorufujiwaraさんに任せっぱなしで、
最後ゴミの片付け手伝ったレベルでした…!
すんません!
togetterでツイートまとめましたのでこちらで雰囲気はわかると思います。
https://togetter.com/li/1243940
(ツイート載せて欲しくない方は編集自由にしていますので削除お願いします!)
当日の映像が動画になっています!
@satorufujiwaraさん ありがとうございます!
https://www.youtube.com/watch?v=TGdAvY5i-sU&feature=youtu.be
DSLの話をしていました。
hadiさんはDSLの話をしていることが多い気がしますね。
今回もジョーク混じえつつの良いトークを聞けました!
FSM DSL in Kotlin
https://speakerdeck.com/tomoya0x00/fsm-dsl-in-kotlin
@tomoya0x00 さん
Kotlin Multiplatform(?)
https://speakerdeck.com/panini/kotlin-multiplatform
@callipanさん
Spring FuをGraalVMで
的なやつ
資料アップしてない?
ブログ記事
https://taro.hatenablog.jp/entry/2018/07/02/090458
@ngsw_taroさん
ビズリーチの方もLTされてましたが、、
みつけたらこの記事に追加します!
あと@yanzmさんが自分の子供にマイクラのmodをKotlinで書いてもらった?的なLTもありました!
せっかくなので、hadiさんに話しかけようと近づいて行ったのですが
英会話ほぼ出来ないので 「I like wasabi」とだけ伝えました。
https://github.com/wasabifx/wasabi
「wasabiはもうkillしたよ」的なこと言われましたw
https://kotlinlang.slack.com/のslackチャンネルとかから#wasabiが消えてたんで知ってたんですけど、直接言われるとなんとなく寂しいですね
wasabiじゃなくてもうktor使って!てことらしいですね。
https://github.com/ktorio/ktor
@shiraj_i さん とか @callipan さんが普通に英語で会話してるのでホォー羨ましいなと思いつつ、
どういう会話かはちょっとは聴き取れるので横で聴いたりしてすごしました。
hadiさんはエヴァンジェリストチームなので世界各国の色々なところを行脚してて、
そのエピソードトークとかがメインだったような気がします!
実際に中の人に会って話す機会はなかなか貴重なことだと思うので
良いイベントでした!
会場提供 & 準備ありがとうございました!
hadiさんまたきてください!
前回に引き続き。
あえて、調べ直す。
リバースプロキシ(英: Reverse proxy)または逆プロキシは、 特定のサーバへの要求を必ず経由するように設置されたプロキシサーバ。 一般的なプロキシとは異なり不特定多数のサーバを対象としない。 リバースプロキシは、不特定多数のクライアントから寄せられる要求に対して、 応答を肩代わりすることにより特定のサーバの負担を軽減したり、 アクセスを制限することにより特定のサーバのセキュリティを高めたりする目的に用いられる。
wikipediaの引用。
https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%90%E3%83%BC%E3%82%B9%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7
分かるんだけどなんかしっくりこない。
何がリバース?
内部ネットワークと広域ネットワークとの接点に置かれ、 外部から内部へのアクセスを代行する。通常のプロキシ(代理サーバー)の「内部から外部へ」と反対であることが「リバース」の由来。
http://www.dnp.co.jp/artscape/reference/archive_words/detail/rvrs-proxy.html
なるほど、通常のプロキシとは逆方向だよということか。
HTTP、TCP、UDP のロードバランシングが出来るらしい。
Layer 7 request routing using URI, cookie, args, and more
レイヤ7はOSI参照モデルのアプリケーション層ですね。URIやクッキーとかを使ってルーティングする機能がある。
Session persistence based on cookies *
クッキーでセッションを永続化する機能がある。
Active health checks on status code and response body *
ステータスとレスポンスボティのヘルスチェック機能がある。
Service discovery using DNS *
DNSを使ってサービス検出する機能がある。サービスディスカバリーってよく聞く言葉だな
ロードバランシングには5種類の方式が使えるらしい。
ラウンドロビン、最小接続数、ハッシュ、IPハッシュ(NGINX Plusのみ)、Least Time(NGINX Plusのみ)。NGINX Plusというのはnginxの商用版らしい。
なんとなく、調べたいので調べます。
enのwikipedia見てみましょう。
https://en.wikipedia.org/wiki/Nginx
The software was created by Igor Sysoev and first publicly released in 2004.
2004年に公式にリリースされたらしいです。
公式サイトを見て見ましょう。
https://nginx.org/en/
以下、引用。
nginx [engine x] is an HTTP and reverse proxy server,
a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev.
For a long time, it has been running
on many heavily loaded Russian sites including Yandex, Mail.Ru, VK, and
Rambler. According to Netcraft, nginx served or proxied 23.76% busiest sites in March 2018.
Here are some of the success stories: Dropbox, Netflix, Wordpress.com, FastMail.FM.
なるほど。
ざっくり、web serverでwikipediaで見てみる。
https://en.wikipedia.org/wiki/Web_server
と、この情報にたどり着いた
https://w3techs.com/technologies/overview/web_server/all
October 2017
Below are the latest statistics of the market share of all sites of the top web servers on
the Internet by W3Techs Usage of
Web Servers for Websites.
Product Vendor Percent
Apache Apache 48.5%
nginx NGINX, Inc. 35.4%
IIS Microsoft 10.8%
LiteSpeed Web Server LiteSpeed Technologies 2.9%
GWS Google 1.1%
All other web servers are used byless than1% of the websites.
Apache強いな。。ざっくりApacheとnginxだけ気にしとけば良いか…(雑)
IISは出くわしたら気にするレベルで良いだろう。。。うん。。
ただ、この情報が統計的にどの程度有意なのかわからない。
ということで、Apacheも知っておきたいところ。
この記事がよくまとまっているように思う。勉強になった。
https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations
Apacheよりnginxの方が後発ということもあり優れている部分もあるが、一方でApacheの方が優れている部分もありそう。例えば、Apacheはモジュールの動的ロードが出来るが、nginxは出来ないのだそう。これは相性によってどちらを選ぶかということも考えたりとかがある気がする。
また、nginxをリバースプロキシにして、併用するパターンもよくあると。
さらっと読んだだけでは理解が足りないのでこの記事を何回か読み直したい。
先ほど書いたように、ざっくりは
ただ、機能もっと色々あった気がする。ので、調べると
https://www.nginx.com/products/nginx/#features
これが出てくる。
なんかこっちのサイトの方が今風だ。
などが書いてある。機能というかfeatureである。
ざっくり追いかけてみましたが、調べきれないので、おそらく続きます。
ベタープログラマは良い本である。
内容に共感出来て、その瞬間何故かニヤける感じ。
それと同時に、自分自身を省みて申し訳なくなる。ああ、すんません。
読んでいると、irofさんとかが喋りそうな内容だなと思う。
俗っぽい言葉で言うとエモいのだが、
プログラマとしてかくあるべきと言うのを思い出させてくれるというか、
“プログラマとしての正しさ”とか”プログラマとしての向き合い方”とかを改めて思い直させてくれるという感じ。
初心にかえるにはもってこいであるし、正しい方向へ向かえる本だと思う。もちろん知らなかった知識の発見や、新しい方法も読者によっては含まれていると思う。
この本はとことん、プロダクト、特にコードを中心にして物事を論じている。プログラマーたるものコードが中心だというのは全く正しい。
しかも、綺麗なコードを書く方法よりも、”今存在している問題をはらんだコードをどう解決するか”とか”いつリファクタリングをするか、どこまでリファクタリングすべきか”など「書き方」よりも「判断の仕方」が書いてあったりするのでよい。
全てを読んでいないし、飛び飛びで読んでいるのですがメモします。
6章航路を航行する
ソフトウェア考古学、いい言葉
7章汚物の中で転げ回る
大事
24章学びを愛して生きる
これが出来なくなったら辛いし、逆にこれが出来て入ればなんとかできる気がする
27章停滞を避ける
気をつけたい
28章倫理的なプログラマ
気をつけたい
29章言語への愛
わかる
30章プログラマの姿勢
そっちか
33章今度こそ分かった
ほんますんません
Javaでvarをとりあえず使って遊んで見ました。のザックリしたただのメモです。
Java 10がリリースされました!Java 9はほとんど触らなかった!
リリース日がちょうど祝日だったので少しだけ触りました。
一番遊んで見たくなるのが、
JEP286のvar のやつですよね。
これにより、ローカル変数でvarが使えるようになります。
JEP 286: Local-Variable Type Inference
うっかりキーボードを衝動買いしてしまったので、メモがてら所感をブログに書いてみます。
魔が差してHHKBとKinesisをポチってしまった
— yank shaving (@yy_yank) 2018年2月5日
今回の記事は、ただのニューストピックです。
15インチのpc買って気づいたんですが、今まで僕が15インチだと思って使ってたpcは13インチでした
— yank shaving (@yy_yank) 2017年12月9日
MacBook Pro買いました。
touch barすごい違和感ある。
毎回散らかすので、はじめにやったことをまとめておこうと思います。
本当はこういうのは1つのインストール用スクリプトみたいになってるのが理想だけど。。
備忘録です。
みんなどうやって作業効率を上げてるのか教えて欲しいです!!!
ポモドーロテクニックを使ってみての実感とかを書きます。
これに対して、「ポモドーロのやり方間違っている」とか
「もっと良い手法がある」など、何かあればやんわり教えていただけると幸いです。
Kotlin Confが羨ましすぎてウォーッてなったので、
ca.kt(Kotlin Conf報告会)に行ってきました。
https://cyberagent.connpass.com/event/70423/
一応、レポートというかログというか思ったことというか。
残しておこうと思います。
タイトルの通り、JavaOne報告会に行ってきました。
僕はJJUGのイベントの中でも、毎年恒例のJavaOne報告会は結構好きです。
みんな海外帰りの余韻でちょっと浮かれた気分が抜けてない感じが良いんですよねー。
本当に個人的な話ですねw
https://jjug.doorkeeper.jp/events/66256
最近ブログを書いてないなと思い、慌てて書く次第です。
先日、2017/9/21に、Java SE 9とJava EE 8がリリースされたようです。
http://www.publickey1.jp/blog/17/java_ee_8java_9eclipse_foundationjava_ee.html
こんなにリリースって盛り上がらなかったっけw
僕の狭い観測範囲あまりワイワイしてる人が少ないです。
せっかくだしちょっとだけ触ってみようと思います。
ホントちょっとだけ。
Java EEは一旦忘れて、Java SEの方のみ。
夏のKotlin LT祭と題して、
日本Kotlinユーザーグループ(JKUG)主催でLTイベントを行いました。
会場を提供していただいたDeNAさん、ありがとうございました!!!!!!
ってなんとなく思った。
いろんな言語を学びたいとか言いつつ、お前が真っ先に書こうとするのはJavaだろう、と。
「Javaが凄い出来ます!得意です!」とかなかなかそういうことを言う気にはならないんだけど、
パッと何かをしようとしたときには一番楽な言語となっている。それかKotlinなんだけど。
多分、Javaに関して言えば、開発環境がすでに目の前にあるから咄嗟に使いやすいというのは大きい。
例えば普段鉛筆を持たない左手で字を書いてみる。
書いているうちに左手で字を書くことを覚える、みたいな作業は必ず必要である。少なくとも僕の場合。
ただ、忙しい時にtryすると、
「この忙しいのになに悠長なことしてんだ」ということになるので時間の捻出もある程度必要になりそう。仕事ならば。
家で趣味コードであればダラダラ書いても良いかもしれないが。
やっぱある程度家で素振りしてから実戦で個人で使ってみるという流れかな。
それでよっぽどチームで使ってメリットがあるならチームで導入という流れになるだろう。と思う。
ホントにそれってJavaでやる方が向いている作業?ってこともある。
もしかしたらPythonの方が良いかもしれないし、JavaScriptの方が良いかもしれないし、
RustとかGoの方が良いのかもしれないみたいなの。
それでも案外Javaで出来てしまったりするからタチが悪いというか。
極端な話Semicolonless Javaみたいなことになる。
まぁそもそもそんな難しいことを僕自身が書いていない。
やっぱり素振りだなぁ。もっとコード書かないと
つまりこういうめんどくささがあります。
val f1 : () -> Unit = {}
f1() f.invoke() // OK
val f2 : (() -> Unit)? = null
f2() //コンパイルエラー
f2?.invoke() // OK
f1()という関数呼び出しは、実は演算子オーバーロードという機能によって実現しています。
f1()とコードを書いた時 f.invoke() が呼び出されるというものです。
f1は () -> Unit 、つまり引数なしでUnitを返す関数型をlambdaで表現したものですが
実体の型はFunction0<Unit> というインターフェースです。
Function0の実装はこうなっています。
// kotlin.jvm.functions
// Functions.kt
public interface Function0 <out R > : Function<R> {
/* Invokes the function. */
public operator fun invoke(): R
}
f1はFunction0自身であり、invokeが実行されます。
これがf2のようにnullableとなった場合にKotlinの演算子オーバーロードはそれを許しません。
f2?.invokeという風に厳密にかけとコンパイルエラーになります。
つまり、nullableな変数の関数呼び出し(nullableな型をレシーバーとする関数呼び出し)をしにくいということです。
前述したコードのf2を、f2?()とかって実行出来れば良いのではという感じもしますが、
Kotlinはそういった言語設計を行っていないようです。
f2?()という呼び出しをサポートする代わりに明示的にf2?.invoke()と書きなさい、としています。
これはnull安全的観点で言うと良いような気もしますが、
突然普段は演算子オーバーロードによって隠蔽されているinvokeという謎関数が出てきた感じになるので、実装者としては混乱するかもしれません。
推測ですが、f2?()とかという書き方をサポートしなかったのは
単純に?を使った記法を利用できる箇所を限定的にしたかったのと、
コンパイラの字句解析とかを簡単にしたい(めんどい)というのがあったのではないかと思います。
nullableだと演算子オーバーロードが利用できないかというとそうではありません。
拡張関数を利用すれば良いのです。
たとえば次のように実装すればinvokeの呼び出しも演算子オーバーロードを介して利用可能です。
operator fun <R> Function0<R> ?.invoke() = this?.invoke()
val f2 : (() -> Unit)? = null
f2() // コンパイル通る
ただし、Kotlinの標準ライブラリとしてわざわざこういった機能を提供せず
f2?.invoke()と書かせているのは、関数を実行したつもりで関数を実行していないなどのバグの元になるのを防ぐといった意図がありそうですしあまりお勧め出来るソリューションではありません。
もう一つ、理由として考えるられるのは
nullableなものを実行した時の対処というのは大体においてコーディングしている側に委ねられるものだと思います。
たとえばBigDecimal + BigDecimal で返されるのは2つのインスタンスの値を加算したものであるのは自明という感じがしますが
BigDecimal? + BigDecimal
BigDecimal? + BigDecimal?
などは何を返すかはちょっと考える必要があります。
あと、単純に標準ライブラリが膨らみますね。
悪ふざけコードです。
https://gist.github.com/yyYank/02d6c7f64532bb30cd0e63563d90feb2
Kotlin入門までの助走読本というfree bookを
僕も参加させてもらって、ちょっと書きました。
楽しかったなぁー。皆さんありがとうございました。
豪華執筆陣による「Kotlin入門までの助走読本」をリリースします!
— 日本Kotlinユーザグループ (@kotlin_jp) 2017年5月29日
話題のプログラミング言語の「味見」をぜひ!PDF注意https://t.co/LJJDReAzue
ぜひ読んだ方はアンケートも書いてみて下さい。ありがたく拝見します。
何も考えずタイトルつけたのに胡散臭い。
どうも、趣味でKotlinの情報を集めてるだけの人です。
KotlinはAndroidで公式採用されることが決まりまして特需が出てきています。
こぞって企業がPRのために「Kotlin使ってますアピール」をしたり、
Kotlinとはなんぞや、みたいな話を書いたりとかしてますので、
この速さなら言える、ということで僕も便乗して久しぶりにKotlinの話を書こうと思います。
プログラミング言語は簡単で、それを難しく語る人や難しく使う人がいるというだけな気がしています。
つまり何が言いたいかというとKotlinは簡単です。あと、ラクです。
僕が今日書こうとしているのはよく分からないボヤキなので単純に学びたいというだけであれば、
Kotlin KoansとKotlinの公式サイトのリファレンスだけ見れば大体充分です。
他の情報はまぁ、あんまり読んでも読まなくても一緒です。(というとアレですね。。)
あ、でもKotlinスタートブックという本は良いです。
あと、僕のサイトも使ってみてね(宣伝)
逆引きKotlin
それだけで良いと思うのでココから先は読まなくても問題ないです。
タイトルかぶりしそうなので変なタイトル。
VMの歩む道。とか言ってHotSpot VMとDalvikとARTの話をしました。
https://www.slideshare.net/yyyank/vm-dalvikartjava-vm
発表者の理解不足もかなりあって、資料見ていただくと簡潔でなかったり
情報として微妙だったりする箇所も多いと思います。
それでも勉強になったと言ってくれる人もいてありがたいです。
(
ホントはJVMS全部読んで
ARTとかOpenJDKの実装ももう少し読んだ上で発表したかった。
JVMSはJava SE8版でPDFだと600ページぐらいです
(注意:pdf) The Java® Virtual Machine Specification
)
ベスト尽くしてこんな感じです。すみません。
訴訟の問題、パフォーマンスチューニングを発表スコープから削ったことで
大分説明しやすいかと思ったんですけど、 それでも広いなとか思いました。
JITとかAOTとかめちゃくちゃ簡単に説明しましたが
プロファイリングした上でその情報に基づいてJITが走ったりするとか色々あるんですけど、
あー、どこまで調べよう&説明しようかみたいな感じでした。
今回はあまり質問なかったか、しにくかったのかもしれません。
後から話しかけに来てくれる人もいたのでその人からは色々意見聞くことが出来ました。
さくらばさんのJigsawセッションを拝聴して
sli.doという匿名質問サービスが良さそうなのでまた機会があれば使ってみたいなと思いました(さくらばさんがツッコまれる世界を初めて見たw)。
データモデル、勉強になりました。咄嗟に出てくるようにしたいなとか思います。いっつもデータモデルのこういうものがあると思いつつも、どのタイミングでそれを使うべきかとか適切に判断できずじまいということが多いです。
色々ためになる内容だったんですけど、アンチパターンはH2Oぐらいに思い出がいっぱいって感じなので素直に笑えなかったです。そーだいさんぐらい声が通る感じになりたい。
さくらばさんのセッションはいつも安定感がすごいです。たしか、全然スライドとか見ずに全部覚えてて話してるとかいう噂を何処かで聞いた気がします。Jigsawに関してはモジュールがうんたらーで最近もめてるやつってぐらいしか把握できてなかったので、勉強になりました。
以下、なんかツイートしてたやつ
JSR 376(Jigsaw)に反対してSE9には賛成という投票が#ccc_g5
— yank shaving (@yy_yank) 2017年5月20日
ソースコードも変える必要がある、コンパイルもpackagingも変わる、実行も変わる、IDEの対応が必要になる(予定)
— yank shaving (@yy_yank) 2017年5月20日
なるほど#ccc_g5
Jigsaw非対応のjarは-cpで読んでくれなくなる
— yank shaving (@yy_yank) 2017年5月20日
Automatic Moduleでjarをモジュールか出来るけどそのあたりがもめているらしい#ccc_g5
automatic moduleはjarファイル名がそのままmodule名になる、、そしたら衝突するだろーという問題
— yank shaving (@yy_yank) 2017年5月20日
MANIFESTにモジュール名書くようにしましょうに変更➡️これが通らないとJigsaw通らなそうとか
#ccc_g5
ビルドツールが対応する必要もあるよな、たしかに…#ccc_g5
— yank shaving (@yy_yank) 2017年5月20日
きしださんぽいなぁと思いました。前半は難しいというか全然知らない分野で雰囲気で聞きました。コーディングのベストプラクティスの部分は納得出来る内容が多かったです。
LINEさんの寿司ちょっと食べましたが美味しかったです。
色々勉強できたし、色んな人と話せたし良かったです。
今回もありがとうございました!みなさんお疲れ様でした!
「イシューからはじめよ」を読んだ。結構良かった。
別にソフトウェア開発とかそっち系ではなく、
もっと仕事をする人全般に当てはまる内容の本。
だけど、自分として役立ちそうなのものとして
という場面が思い浮かんだ。
なのでシステム開発で「開発が終わらない」とか「バグの解析が苦手」とか、
勉強会で「プレゼンの資料が上手く作れない」とか悩んだりしてる人は読むといいのかもしれない。
プログラミングをするお仕事をして数年経つけど(5年ちょいぐらい)、段々と守破離が出来なくなってきた気がする。
剣道や茶道などで、修業における段階を示したもの。「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階。「破」は、他の師や流派の教えについても考え、良いものを取り入れ、心技を発展させる段階。「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階。
https://kotobank.jp/word/%E5%AE%88%E7%A0%B4%E9%9B%A2-689006より引用
この守破離という言葉は、近い職業で言うといわゆるITエンジニアの意識高い系の人たちが使っている気がするのだけど考えとしては大事と思っている。
で、出来なくなってきてると思っているのは主に「守」の部分。
トレードオフ的な。
例えば、新しい言語Aを学ぶとなったとする。
そうすると、プログラミングを初めたばかりであれば入門書から全て基本文法を覚えたりとか始める。
次に何かアプリとか作ってみようとする。そして仕事で使うとかする。
一方で、それが今の僕であれば基本文法は入門書を細かく見なくても◯◯言語のアレと同じだからやんなくても大体分かるな、となる。
A言語とB言語があった時に、AのXXXX ≒ BのXXXX とか判断出来る。
一見して便利なんだけど、全然手とか動かさなくて済んでしまう。もしくはそれで済まそうとする。記憶に残らないし身につかない。
性分として、元々あたまでっかちな方なので結構質が悪い。
言語の違いの部分だけ味見して分かった気になるとかそんな感じになってて中途半端だなぁ、、とかいうのが最近です。
ということで、僕がやっているのは守のない守破離みたいな感じになっている。かもしれない。
帽子のないマリオ、バクダンを持ってないボンバーマン、具のないカレー、みたいになんか足りない感じ。
そもそも破も離も出来ないはずなので、完全にわかったフリということになる。厳しい。
ここ最近思うのはもっと愚直にやりたいなということ。
もちろん、分かりきっていることをド初心者と同じように学ぶというのは効率が悪いのでやらないですが、もっと色んなことに真摯に向き合いたいなとか思う所存。
という自分の悩み?と自戒を書いた風のポエムでした。
うだうだ言ってないでコード書け的なやつだ。
ござ先輩さんのアレを読んだ。
Javaで「はじめてのプログラミング」を教えるのはキツイと思った話
Javaに造詣が深い方だった気がするし、色々考えた上でそういう決断するのは確かになぁーと思った。
イマドキ、Servletさわんのかぁとか思いつつ、Servletそんなムズいんだっけと思いつつ。
で、脱線して僕ならJavaの研修課題どんなものを作るかなとか考えた。
って前に聞かれたけど、スッと答えられなかったのでここに記します。
※このあたり(https://speakerdeck.com/ntaro/kotlinwoshi-meyouhanzuon-number-droidkaigi-number-droidkaigi6?slide=41)
#DroidKaigi6 みんなモクモクしてる! #kotlin pic.twitter.com/awlwcsoYg7
— DroidKaigi(Official) (@DroidKaigi) 2017年3月10日
DroidKaigi2017、運営面とても快適でした。
発表者、参加者、スタッフでうまく成り立っているかなぁという風に思い色々感謝です。
僕個人としては快く休ませてもらえた会社にも感謝です。
あ、でも会社の宣伝全然出来てないや。すんません。
(ていうか皆さん平日2daysで休み取れるなんて良い会社ですね?僕は自分の判断で1日参加でした)
あと、チューターとして誘えてもらったたろうさんにも感謝。
オライリーが出版しているマイクロサービスアーキテクチャの読書会に参加してきました。
第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会
今回は6章です。
この読書会は「本の内容をなぞって担当者が発表」→「ディスカッション」という形式をとっています。
6章のテーマは「マイクロサービスにおける」”デプロイ”に関してです。
が、まぁ本の内容をなぞって説明をしてもらって、話を聞いている間に6章を初見で読んで、これは嫌な予感がするなーと思いました。
その時の感想がこちら。
6章自体内容に対してページ数すくなすぎる感ある(本が)#MSA読書会
— やんくです (@yy_yank) 2017年2月18日
ドメインの境界がハッキリしていない時っていつ?とかそれは開発の度のタイミングからハッキリしてきてCIビルドとか分割できるの?とか
— やんくです (@yy_yank) 2017年2月18日
それ5章に書いてあるのかな#MSA読書会
他の章をきっちり読めてないっていうアレな状態なんですが、とにかくこの章はCI/CDというテーマに対して文書量が少ない。かつ、マイクロサービスアーキテクチャについてのCI/CDって意味での深掘りが無いです。
したがって、これはCI/CDの話に内容がすり替わってしまってマイクロサービスの文脈からは離れてしまうのではないかという懸念がありました。
結果的にやはり「マイクロサービス」の文脈というよりはCI/CDのディスカッションという意味あいが強くなってしまったんじゃないかなぁと思います。6章を語る上でおそらく、CI/CDというのは「前提」であって「本論」ではないんですが、どうしても自動化とかそっちの方にディスカッションの話題が行ってしまいがちでした。
本来ならマイクロサービスの文脈でCI/CDとはどうあるのが良いかというディスカッションになれば良かったんですが。
どっちかというと、CI/CDやってますよね? やってます or やってませんみたいなレベルになってしまって少しもったい無かったかなと思います。
だって、自動化とか別に出来てても出来てなくても良いですけど。この本の主題は、マイクロサービスですから、マイクロサービスにおいて自動化はどうあるべきかに注力出来た方がホントは良いのです。
結構座席的には面白い人が集まっている島だったんですが、マイクロサービスと組織論的な話が面白かったです。SIの文脈においてはマイクロサービスのサービス単位でチームが出来て縦割りになる。その際の政治的な問題とか。
はたまた「過剰なマイクロサービス」の話も面白かったです。CRUDでサービスが分かれるとか。Spring系のマイクロサービスの本とかであるんですって。まぁサンプルとしてはCRUDとかでサービス分けると分かりやすいんでしょうけど。実際やりすぎなんですよね。
でも技術書とかのサンプルがそうなっちゃってるから偉い人が「それが正しいんだ!こういう風にしよう!」みたいなことになったりするらしいです。
マイクロサービスで考えてた時、本にも書いてありますが、CIとCDはあって当たり前かつ、必要不可欠な存在です。かつ、筆者の主張に従うと、1サービス、1リポジトリ、1ビルド(CI)という比率であるべきと言っています。
加えてローカルでの再現が難しい。「バランスを考えてローカルでも環境を作るべき」、と。
また低速のテスト、高速のテスト、UAT、本番などで環境を変える場合はそれぞれの環境の違いを考慮する必要がある、など。
正直このあたりはもっと本の中で掘り下げて欲しいところで、もっと色々ケーススタディがあると思うんですよね。
でもきっと筆者的にはこの章はこのページ数で収めないと、、、とかあるわけです。(はしょりたくないけど)その大事なことをはしょっているんだろうなと言う感じを僕としては強く受けました。
Docker、Ansible、Vagrant、Vaultなど結果的にCI/CDツールの詳解で終わってしまったような章でした。
うーん、ちょっともう少し説明する必要あるだろうみたいな気持ちでしたが。で、そういうツール郡を熟知していればそっちにとらわれなくて済んだんでしょうけど。。。。
なかなか読書会の皆がそんなの当たり前に知っているというわけではないんですよね。
という感じで、なんだかモヤモヤしてしまう章ではあってのですが、学ぶこともたくさんありました。
みたいな話です。このあたりはマイクロサービス的に大事な内容なんじゃないかなと思います。
といっても、全てがこれに当てはまるわけではないですが、理想的にはこの体系にしていくのが良いのかなという感じです。
例えば、1リポジトリに複数のサービスがある場合は、サービスの境界を意識せず、複数のサービスに対してコミットしてしまいがちとか。つまりリポジトリが同じであるためコーディングをしていると無意識にモノリシックになりやすいということを言っています。(本の中だとあっさり書いてますけど)
ということで、(初参加で言うのもなんですが)ディスカッションとしては今回はもったい無かったのではないかと思います。CI/CDの話になっちゃったから。その話をするのであれば、CiICDの勉強会をやれば良いと思うわけです。
ただ、そうは言ってもマイクロサービスやCI/CDの周辺のメリットデメリットなどの再確認にもなったので良かったのかなと思います。
良い本なので感想とか僕の考えてることを書こうと思います!
「わかる! ドメイン駆動設計~もちこちゃんの大冒険~」というTechBoosterさんが出している本です。
DDDだからページ数多いんだろうなというイメージだったんですが、60ページ。しかも1000円は安い。
買ってハズレでもちょっと1日御飯を控えめにするだけでなんとかなる(大体控えめにすることはない)。と思いPDF版を買いました。
こちらから買えますよ!まわしものじゃないけどw
https://techbooster.booth.pm/items/392260
引っ越しました!世田谷公園には行ったことがありません!
渋谷、三軒茶屋、中目黒などそのあたりで飲む際にはお誘い下さい!!!
それ以外の場所で飲む場合も誘って下さい!
電車通勤の消耗を抑えるために、というのが一番大きいです。
年々電車通勤する体力が減退している。。
徒歩通勤になるので電車とおさらばというのが嬉しいです。
あと、前の部屋は安くて広くていい部屋だったのですが、
川沿いの大通り沿いに面していて、走りたがりなバイクとか、スポーツカーなどのブォンブォン言う音、
救急車消防車のサイレンの音などに悩まされていたため引っ越したいという気持ちがあったことなどもあります。
引っ越しお考えの方は、大きな道沿いの部屋はやめといた方が良いです
— やんく������ (@yy_yank) 2017年1月8日
車や、特にバイクの音が結構うるさいです
引っ越しは勢いが大事です。会社から補助してもらえる部分もあって勢いがつきました。
渋谷、三軒茶屋、中目黒などそのあたりで飲む際にはお誘い下さい!!!
それ以外の場所で飲む場合も誘って下さい!