- 有休…
- 病休…
- 育休…
- 年収(月給、賞与など)…
- 残業代…
- 早朝/深夜手当…
- 休出手当…
- 住宅補助…
- 「ソフトウェアテストのレトロスペクティブ」kyon_mm
- 「皆さんが聞きたいkyon_mmのこと、私が答えます!」kaori_t_spica
- 「アンケートで書いてくれた質問に答えます!」kyon_mm
- 「Groovy(G*)によるSIer閉鎖空間サバイバル術」nobusue
- 「型とは何か? - CPythonの実装」cocoatomo
- 「mercurialとbazaarとpythonメタプログラミング(狩)」wonderful_panda
- 「テストの戦略や計画を支えるマサカリ抑止力(狩)」goyoki
- 「F# のinlineと型推論(狩)」gab_km
- 「F# のコンピュテーション式かモナド」 pocketberserker
- 「Scalaの楽しさ(狩)」kmizu
Ruby の HTTP クライアントライブラリ Faraday が便利そう
API ラッパの開発には [RestClient gem][rest_client_gem] だとか
OAuth の必要なものは [Net/HTTP][net_http] + [OAuth gem][oauth_gem] を使ってた
[Twitter gem][twitter_gem] や [Instagram gem][instagram_gem] など API ライブラリのソースを読んでみると
[Faraday gem][faraday_gem] というものがよく使われてた
Git 2.26.0以下*1には、細工したリポジトリをgit clone
したときに、
そのユーザーのCredential(たとえばGitHub.comをcloneするときに使う認証情報)を奪い取れる脆弱性があります。
📝 取得できる認証情報は credential.helper
の設定に依存する
既にPoC(検証するためのコード)もあり、結構簡単なので是非Gitを2.26.1以上にアップデートしましょう。 git submoduleを使うと見た目ではわかりにくい攻撃もできるので、「気をつける」では回避は難しいです。
* Only the releases of the stable versions are listed in principle. The releases of the unstable versions especially considered to be important are indicated as "not stable." | |
* The branches used as the source of each releases are specified, and the branching timing of them are also shown. BTW, before subversionizing of the repository, the term called "trunk" was not used, but this list uses it in order to avoid confusion. | |
* In order to show a historical backdrop, big conferences (RubyKaigi, RubyConf and Euruko) are also listed. About the venues of such conferences, general English notations are adopted, in my hope. | |
* ruby_1_8_7 branch was recut from v1_8_7 tag after the 1.8.7 release because of an accident. | |
* 1.2.1 release was canceled once, and the 2nd release called "repack" was performed. Although there were other examples similar to this, since the re-releases were performed during the same day, it does not write clearly in particular. | |
* Since 1.0 was released with the date in large quantities, the mi |
こんにちは。 @katzchangです。
VOYAGE GROUPでは人事評価制度の一つとして技術力評価会というのが年に2回ほど開催されて、半年くらいの仕事から何かテーマをピックアップしつつ、別チームのエンジニア2名とお話をしつつ、なんと評価までされてしまうという、とても楽しい会があります。
評価する側のエンジニアも多様で、ある程度の評価軸はありつつも、それぞれの質問や評価はそれなりに個性が出るものだろうなーと眺めています。ということで、私なりの質問や評価のポイントをいくつか挙げてみます。
ja: | |
errors: | |
messages: | |
not_found: "は見つかりませんでした" | |
# not_found: "not found" | |
already_confirmed: "は既に登録済みです" | |
# already_confirmed: "was already confirmed" | |
not_locked: "は凍結されていません" | |
# not_locked: "was not locked" |
- ダッシュボード
- 何も考えずに各モデルをカウントするのでレコード件数増えるとえらいことになる。