I use Protobuf Support Plugin for syntax highlighting. However, it can't resolve 3rd party proto file like this:
In my case, the file which is not resolved is located in proto/third_party directory.
File -> Project Structure or Cmd + ; )Resource rootFinally, unresolved error was gone 🎉🎉🎉
Devices で No product name (No manufacturer name) にチェックを入れることで解決するIntelliJ IDEAをTouch BarありのMacBookProを使っている場合、Shift + F6(Rename)やOpt + F7(Find Usages)のようなFunction Keyと組み合わせたショートカットキーが動作しないという問題に長年苦しめられてきた。特にIntelliJはFunction Keyとなにかを組み合わるショートカットが多くて、これはIntelliJ使いとしては死活問題だった。
この問題のせいで「MacBook ProもTouch Barついてるのか？じゃあ買うのやーめよ」と本気で考えるぐらい困っていた。そして実際Touch BarがないMacBook Airを買う寸前だった。
MacBook Airを購入する寸前で「もしかしたら解決方法があるかもしれない」と思い、いろいろとググってみた。しかし検索しても引っかかるのはIntelliJのTouch Bar Supportの記事ばかり... しかし、IntelliJのフォーラムのコメントを熟読していたところ、以下のようなコメントがあった。
Ok, did som further debugging and tracked it down to Karabiner Elements (which I have installed) - quitting it fixed the problem. It seems that they have a number of conflicts with the touchbar
おっ、もしかしてKarabinar Elementsがなにか悪さしているのか？と思い、試しにKarabinar-Elementsを落としてShift + F6を試したところ Renameが動く。動くぞ...！！！
というわけで、 IntelliJ Touch Bar Karabinar Elements function keys というキーワードでググったところ、冒頭で紹介したKarabinar-ElementsのIssueにたどりついた。そして以下のスクショのようにNo product name (No manufacturer name)のチェックを入れて見事Shift + F6が効くようになりましたとさ。
というか、2017年に解決されていたのね、、、ググる力が足りなくて3年も我慢してしまっていた。
Touch Bar + IntelliJ のファンクションキーが効くようになり人権を取り戻しました。
今年の2月ぐらいからGitHub Actionsを仕事で使うようになったので、実際に使ってみて便利だったものを紹介する。
Slackへ通知するActionはいくつかあるけど、これが一番きめ細かく送る内容を設定できてかゆいところに手が届く感じだった。
たとえばmasterとdevelop branchがあるとして、masterにcommitがあった時にmaster -> develop に対して差分のpull requestを自動で作ってくれる。自分たちはそれを確認してマージすればよい。
設定ファイルを書くことで「このディレクトリ配下のファイルが更新されたら」とか「この拡張子のファイルが更新されたら」とかの条件でPull requestにラベルをつけることができる。難点なのは、以下のような時にラベルを自動で削除してくれないこと。
LRU Cacheは何かをキャッシュする際によく使うデータ構造の一つだと思う。よく使う一方でその実装はやったことがなかったので、今回Goで実装してみたよ、という話。
Least Recently Used Cache のこと。一定のキャパシティを持つもので、キャパシティを超える場合使用された時間がもっとも古い要素から削除される。詳しくはWikipediaを見てもらうと良いと思う。
まずは単純に実装してみた。テストも含めると上記の3つのファイルから構成されている。lru_cache.goには以下のようなGetとPutメソッドがinterfaceとして定義されており、その実装がdefault.goにある。
type LRUCache interface { // Get returns value for `key`. Returns -1 if not found Get(key int) int // Put sets value with key Put(key, value int) }
example_test.go で使用例が書かれており、これを
cache := lru_cache.NewDefault(2) cache.Put(1, 1) cache.Put(2, 2) fmt.Println(cache.Get(1)) // References key `1` cache.Put(3, 3) // This operation evicts key `2` // Output: // 1 // -1 fmt.Println(cache.Get(2))
上のコードにあるように、cache.Put(3, 3) によって一番参照が古いkey 2 がcacheから削除される。結果として、cache.Get(2)は-1を返す。これがLRU Cacheの基本的な動作である。
キャッシュするアイテムはmapを使って管理する。この時、「いつ参照されたのか」を判断するために、mapのvalueには以下のようなitem構造体を保存する。
type item struct { value int age int }
なお、item.ageはそのアイテムがGetで参照された時またはPutで追加された時のageとなる。そのため、LRU Cacheの実装をしている defaultLRUCache ではGet/Putが呼ばれるたびにcurrentAgeというフィールドをインクリメントする。
type defaultLRUCache struct { capacity int values map[int]*item currentAge int mutex *sync.Mutex }
Getの実装はシンプルで、以下を行うだけである
func (c *defaultLRUCache) Get(key int) int { i, ok := c.values[key] if !ok { return -1 } c.mutex.Lock() i.age = c.currentAge // `Get` also increment current age c.currentAge++ c.mutex.Unlock() return i.value }
Getに比べるとPutはやや複雑である。
という操作を行う。またそれぞれの操作で currentAgeをインクリメントする。
func (c *defaultLRUCache) Put(key int, value int) { c.mutex.Lock() defer c.mutex.Unlock() if i, ok := c.values[key]; ok { // If the key exists, update its value and increment its age for this key i.value = value i.age = c.currentAge c.currentAge++ } else { if len(c.values) >= c.capacity { // Search key with least age when over capacity before setting key and value leastAge := math.MaxInt32 leastAgeKey := 0 for key, item := range c.values { if item.age < leastAge { leastAge = item.age leastAgeKey = key } } if leastAgeKey != 0 { // Evict least age key from cache delete(c.values, leastAgeKey) } } // Set key and value to cache c.values[key] = &item{ value: value, age: c.currentAge, } c.currentAge++ } }
このdefaultLRUCacheの実装には一つ大きな問題がある。というのは、capacityを超えている場合、ループで一番ageが小さいものを探しているため、O(n)のコストがかかる。これについては長くなるので別の記事でまとめようと思う。
LRU Cacheのとてもシンプルな実装をやってみた。簡単なので面接の時の課題として出してみるのも面白いかなと思った。
Wrote a blog post about GitHub Actions.
6 hours 50 min.
No progress...
live English.