https://dev-productivity-con.findy-code.io/ 株式会社SODAのセッション資料です。
フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話
https://dev-productivity-con.findy-code.io/ 株式会社SODAのセッション資料です。
腰痛エンジニアを支える技術
ぎっくり腰（椎間板ヘルニア）からの坐骨神経痛により、ほぼベッドから動けない状況になってしまったので、そのような中でも何とかコードを書くための技術をまとめました。 💻 道具編 最初にベッドの上で快適に PC を使えるようにするための道具を紹介します。 ごろ寝デスク 2 知る人ぞ知る腰痛エンジニアの必須アイテム。 これを使えば、腰を極力刺激せずベッドの上から PC を操作できるようになります。 しかし、一見完璧にみえるこの製品にも問題が。。 使うとわかるのですが、手を上げながらのタイピングは地味にきついです。モデルの方のようなフォームで使うと、腰の代わりに肩・手首・肘を壊すのも時間の問題です 🥲 そこで次のアイテムが必要になります。 ワイヤレスキーボード ごろ寝デスクを使いながら肩・手首・肘を守るためには、ワイヤレスキーボードが必須です。ワイヤレスキーボードがあれば、手をおろした状態でタイ
西暦1年は閏年か？ - プログラマーの脳みそ
閏年（うるうどし）の話題。 Twitterで見かけた話題で「西暦1年は閏年かどうかぱっとわからん人おる？」という些か煽り気味のツイートを見かけたのだけども、反射的に「閏年じゃないに決まってるじゃん」とぱっと答えてしまわないだろうか。本当にそうだろうか？ そう単純な話なのだろうか？ プログラミングを学んでカレンダーを扱うことを学ぶ際に置閏法についても簡単に触れられることがある。置閏法というのは閏年や閏月（太陰暦では1年が13ヵ月になるケースがあり追加の月を閏月と呼ぶ）をどのようなルールで挿入するかという話で、まさにアルゴリズムであるからプログラミングの話題と相性がいい。 置閏法 現代の西暦の置閏法（ちじゅんほう）は 西暦を 400 で割り切れる年は閏年 上記以外で西暦を 100 で割り切れる年は平年 上記以外で西暦を 4 で割り切れる年は閏年 上記以外は平年 といった手続きで閏年（つまり2月
Stack Overflowに高校時代から10年間書き込みを続けたエンジニアが学んだ15のこと
by Glen Noble 多くのエンジニアが自分では解決方法がわからないプログラミングコードの書き方やエラーをStack Overflowで調べますが、そのStack Overflowで高校時代から10年間モデレーターとして書き込みを続けたMatt Biernerさんが、これまでの経験から学んだ「Stack Overflowを使う上で覚えておくべきこと」をリストアップしています。 What I've learned over 10 years on Stack Overflow – UWTB https://blog.mattbierner.com/10-years-stack-overflow-learnings/ ◆01：質問することもスキルの一つ 質問をすることは簡単に思えますが、回答を得られる質問をするには単語を選ぶことが重要となります。Stack Overflowにも公式の質問
多くのCPAN Authorに育てられ、息をするようにCPANモジュールを書けるようになり、そして分かったこと
多くのCPAN Authorに育てられ、息をするようにCPANモジュールを書けるようになり、そして分かったこと
侍エンジニア塾とAidemyの杜撰さから学ぶべきこと - Qiita
（2018年11月8日追記） アイデミー代表の石川様よりコメントをいただきました。丁寧なご対応ありがとうございます。 ぜひこちらも一読ください。 先日、プログラミングの勉強を始めようとしている知人から「Aidemyをやってみようと思うんだけど、どう思う？」と相談されたので無料公開されている「Python入門」を試してみたところ、その内容があまりにも杜撰で驚きました。 最近炎上した侍エンジニア塾のブログ記事と、偶然やってみたAidemyの教材を見て、 プログラミングを勉強する人 プログラミング関連の記事を書く人 オウンドメディアを運営する企業 学習サービスを運営する企業 個人 が学ぶべき・気をつけるべきだと感じたことを書いておきたいと思います。 ここでは、侍エンジニア塾とAidemyをそれぞれ、 オウンドメディアでプログラミング関連記事を公開している企業 事業（学習サービスなど）としてプログ
エンジニアが転職する時のチェックリスト - とりあえずやってみればいいじゃん
この記事は退職者その2 Advent Calendar 2017の17日目の記事です。 今年に入ってこれからの生き方を考えた結果、某社を退職しました、転職して3ヶ月。現在の話と勉強会復活のお知らせ。という2つの転職系記事を書いており、こっち方向のネタは尽きたので転職活動を焦点にした記事にしようと思います。 エンジニアが転職する時、いろいろな軸で会社の良し悪しを決めていくと思います。ただ、「自分では○○が重要だと思ってそればっかり見てたけど今にして思えば△△もちゃんと見ておけば良かった」となってしまう時もあります。なのでとりあえず会社を見る上でチェックポイントになりそうな項目をひたすら並べていこうと思います。この中で「これは重要だな」と思う項目があったら、転職活動する時に確かめてみてください。 ※ちなみにもちろんですが私は転職する時に以下に挙げる全ての項目をチェックしたわけではありません。単
エンジニアが転職する時に考えることを採用面接官をしてる立場から書いてみた - Qiita
エンジニアの転職メモ を読んで、刺激を受けたので書いてみました。 非常に共感しました！ 自分的にちょっと気になるところ+αを書こうかなと。 書かれたことは会社的な方針ではなく、個人としての観点です。 自分誰よ とある企業で採用の一次面接に呼ばれたりする現場のエンジニアです。 Javaエンジニアです。Scalaもたまに書いてました。 転職回数は片手では足りないくらいの回数をしています。 最近はエンジニアマネジメントの比重が多く、ほとんどコード書いてないです。 コードは書いていませんがレビューや調査では読んだりします。 アーキテクチャ、フレームワーク選定、インフラ方針などの決定権は持っていて、 ビジネスバランスを取りながら実装の方針などを決めます。 採用面接官のエンジニアは現場エンジニアが多い 人事によるピックアップとは別 前提として技術力はエンジニアしか判断できないと思っています。 でも、採
若手エンジニアを不幸にしないための開発の「べからず」集 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の）若手は、将来も働き続けるための力を付けるための組織内での教育が、（昔ほど）なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業前提の仕事のスケジュールを組織がたてることが多い。（その分野の理論を知っていれば自明のことを実験で証明することを要求されるのは苦痛である。） 設計指針の「べからず」 何ができれば十分かを明確にしない 開発目標は、何ができれば十分なのかを明確にしないまま、追加
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What is "engineer to manager" ?
わたしがインフラエンジニアになった理由