開発チームのチームリーダーやってたときってどんなこと考えながらやってた?って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
今の時代、長く勤めれば自動的に給料が上がるのが望ましいと考える人は少ない。その一方で、日本企業の給与制度には年功序列の考え方を引きずるところが多い。働き方改革に取り組む企業の多くは、「労働時間の削減」、「テレワークの推進」、「ダイバーシティの向上(女性活躍推進を含む)」などに取り組むが、給与制度にまで切り込まないのはなぜだろう? 「残業をやめましょう」、「失敗を恐れず挑戦をしましょう」――、いくら掛け声をあげても、制度を作っても、行動に報いる報酬を与えないのであれば、社員は「会社は本気でない」と受け取り、組織を支配する古い価値観は消えないだろう。 社員の働き方を変えたいなら、給与制度まで切り込むべきではないか――、という考えの下、ユニークな給与制度を運営している5社に取材した。 社員の“主観的”相互評価を元に基本給を決定ITを活用したサービスの企画・制作・運用から不動産や葬儀事業にまで幅を
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか?」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった(五段階評価で4と5が半数ずつ)ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
vim-jp/issues のパクリです。 https://t.co/V6MpMfF3q7 前々から作りたいと思っていた rubocop-jp を作りました。英語でバグ報告とかつらいよーという人のためのアレです。 ついでにそのへんの興味ありそうな人を雑にorgに招待しました— Pocke(ぽっけ) SW-1309-2807-5790 (@p_ck_) 2017年11月12日 これは国単位の話ではなく言語単位の話なので、jpよりjaの方が正しいなーとは思うのだけど、日本に限っては国と言語がカバーする範囲が一緒だからまあどっちでもいいかなーとなってしまった。あとvim-jpのパクリだからjpでいいかなって— Pocke(ぽっけ) SW-1309-2807-5790 (@p_ck_) 2017年11月12日 なにこれ RuboCopへの機能要望、バグ報告、質問などを日本語で気軽に出来るところがあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く