はじめに 成長したいと思っていても「どこから情報を集めればいいのか分からない..」という人は案外多いのではないかと思います。 そんな方へ向けて、私が普段情報収集に使っているリソースをご紹介させていただきます。 ただ紹介するだけでは、味気ないので、簡単に一言二言の紹介コメントを付けて、ご紹介させていただきます。 紹介に関しては、独断と偏見が混じっているかも知れませんが正直な意見として書かせていただきます。 IT系ソーシャルメディア ◆ Qiita この記事を見ている時点で、Qiitaの存在は認識できているので、わざわざ紹介する必要もないと思いますが、一応... 2011年に「プログラマの問題解決サイト」と銘打たれてスタートした、エンジニア情報共有に特化したソーシャルメディアです。 ◆ Qrunch 「もっと気軽にアウトプットできる」がコンセプトという作成者の優しさがにじみ出るような、技術ブロ

はじめに こんにちは、モチベーションクラウドの開発にフリーのフロントエンジニアとして参画している@HayatoKamonoです。 この記事は、「モチベーションクラウド Advent Calendar 2019」10日目の記事となります。 概要 Web系の開発をしているエンジニアであれば、Chrome DevToolsをよく利用されている方も多いかと思います。 特にフロントエンドエンジニアであれば、毎日のように、お世話になっているのではないでしょうか？ しかし、Chrome DevToolsは多機能であるがゆえ、あまり知られていない機能も多いはず。 そこで、この記事では、私が普段よく使っている機能や、今年になって知った便利な機能、面白い機能をまとめて紹介して行きたいと思います。 Console編 CSS - consoleを華やかに console.log('%cHello Qiita',

DRMフリーのePub/PDFのみ。 iPhoneのiBooksに何も入ってなくて寂しい人にもおすすめ。 LPIC Linux標準教科書 Linuxサーバー構築標準教科書 高信頼システム構築標準教科書 Linuxセキュリティ標準教科書 達人出版会 ケヴィン・ケリー著作選集　１ - 達人出版会 ケヴィン・ケリー著作選集　２ - 達人出版会 ケヴィン・ケリー著作選集　３ - 達人出版会 CSS 2.1仕様 日本語訳 EPUB版 - 達人出版会 FuelPHP Advent Calendar 2012 - 達人出版会 FuelPHP Advent Calendar 2013 - 達人出版会 O'Reilly O'Reilly Japan - EPUB 3とは何か？ O'Reilly Japan - Cloudera Impala Git関連 Pro Git 日本語版電子書籍公開サイト 公式の日本

友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通

だいたいのことははてブにまとめてます。 engineerに関するtwisted0517のはてなブックマーク この記事はブックマークから社会人プログラマー1年生向けのものを抜粋したものです。 気が向いたときに更新されることもあります。 考え方とか働き方の話 新人におくる、怠惰な社会人になるための７の方法 : けんすう日記 ｢怠惰である｣というのはプログラマーの資質として結構大切。 頑張って手数で勝負するような人間になっちゃうと、本来楽をするためのプログラムで楽をできないという本末転倒なことになっちゃうので。 個人的には｢楽をするためなら徹夜も辞さない｣というスタンスが割りと好き。 優れたプログラマーの7つの資質 - ZDNet Japan やまもといちろう 公式ブログ - 「できない」ことは恥ずかしいことじゃない - Powered by LINE 成長しないプログラマーの7つの悪習慣 :

この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。（最近のゲームなどは除く）またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を