エンジニアが転職する時のチェックリスト - とりあえずやってみればいいじゃん
この記事は退職者その2 Advent Calendar 2017の17日目の記事です。 今年に入ってこれからの生き方を考えた結果、某社を退職しました、転職して3ヶ月。現在の話と勉強会復活のお知らせ。という2つの転職系記事を書いており、こっち方向のネタは尽きたので転職活動を焦点にした記事にしようと思います。 エンジニアが転職する時、いろいろな軸で会社の良し悪しを決めていくと思います。ただ、「自分では○○が重要だと思ってそればっかり見てたけど今にして思えば△△もちゃんと見ておけば良かった」となってしまう時もあります。なのでとりあえず会社を見る上でチェックポイントになりそうな項目をひたすら並べていこうと思います。この中で「これは重要だな」と思う項目があったら、転職活動する時に確かめてみてください。 ※ちなみにもちろんですが私は転職する時に以下に挙げる全ての項目をチェックしたわけではありません。単
社内Wikiに情報を書くときに守ってほしい、たったひとつのルール - 無印吉澤
このページについて これは、社内 Wiki に情報を書くときに、私が個人的に守っていて、チームメンバにもできるだけ守ってほしいルールの紹介記事です。このルールを実際に運用するためのコツについても、基本ルールの派生という形で紹介します。 想定する環境 この記事は、社内に Wiki があって、フォーマットが決まったドキュメント（仕様書や手順書など）とは別に、各人がメモを自由に書いて共有できるような環境を想定しています。 Wiki の種類は問いません。PukiWiki、MediaWiki、Confluence、Esa、Redmine などのプロジェクト管理ツール付属の Wiki などなど……何でもいいです。Word 文書などにも適用できなくはないですが、文書を気軽に分けるのが難しい場面には、あまり向かないかと思います。 ルール：「このページについて」という欄をページの先頭に用意し、そのページの概
日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。
先週書いた10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。という記事がまずまずの反響を得たのですが、僕の予想とは異なり、「こんなに多くのツールやフレームワークを必要とする現状はおかしい」といった、状況批判の意見が多く集まりました。 Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており、この半年間ほどは「実際にどの組み合わせがベストか」という議論が行われていました。そして、そういった議論もようやく落ち着きを見せ、おおよそ僕が書いたような組み合わせに帰結しつつあります。 そのため、まさか「フロントは変化が激し過ぎる」とか「保守が大変そう」などといったような、1年くらい前に言われていた意見が、いまだに多くを占めるとは、まったく予想していなかったというのが正直な意見です。ひと昔まえであれ
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
分散プログラミングモデルおよびデザインパターン - kuenishi's blog
同名の某記事について。僕がタイトルから想像する期待を、なんだか意外な方向に裏切ってくれた記事であった。批判するだけではよくないので、同じタイトルで僕ならどういう話になるか…という話をしよう。絵のない長文だ覚悟して読め(ΦωΦ)ﾌﾌﾌ…。 分散プログラミングモデル プログラミングモデルとはなんであろうか。 …CもJavaもMPIも登場していない1972年の論文を持ってこられてそれがオリジナルだみたいなこと言われてもえー…って感じで、Flynnの1972年の論文は並列計算やHPCの方面へ非常に大きな影響を与えていると思う。ただしそれはCPU内の話であって、時代が進むと共にたとえば牧野先生の日記「並列計算機のプログラミングモデル」で書かれているような議論につながるといえば繋がるには繋がるが、このレベルで計算を並列化する議論にしか応用できない。せいぜい、プログラミングモデルとひとくちにいっても様々
開発環境のパフォーマンスチューニング - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 クックパッドでは、ユーザーが快適にサービスを利用できるように本番環境でのパフォーマンスを向上させるための様々な工夫がなされています。 ところでパフォーマンスを気にするのは本番環境だけで良いのでしょうか？ 開発環境に目を向けると、そこにもユーザーがいます。開発者です。開発環境のパフォーマンスが向上することで、開発者が快適にサービスを開発できるようになります。 今回はそういった開発環境でのパフォーマンス向上のための取り組みについてご紹介します。 ※ なお先日 Ruby2.2化されました が、今回紹介するものはそれ以前に実施されたため、Ruby2.2で同じ結果になるとは限りません。 状況 今回対象とするのはcookpad.comのアプリケーションです。 近年はMicroservices化を進めていますが、それでも本体のレシピサービスのアプリケーションは依然として非
地方IT企業の時計は20年前から動いていないのでは - Life is Really Short, Have Your Life!!
僕の最近の楽しみは全国の地方IT企業のWebサイトを片っ端から巡回すること。下記リストにある秋田県を現在見ています。 IT・SIer・ゲーム企業リンク集(WEB企業リスト): 秋田県 30社近く見てきて感じたことを書きます。 メインの顧客は各種公的機関 地方自治体が100%って明記している会社さんもあったぐらい、公共機関の比率が高い。地方自治体・なんとか福祉法人・なんとか組合・JAなど。歴史がある企業ほど、民間の企業の仕事の比率が滅茶苦茶少ない傾向にある。無いんだろうねぇ、業務システム開発の機会なんて。 20〜30年前の地方のIT需要なんて公共と金融ぐらいしか無いので、そこを抑えたシステムを開発した会社さんが生き残るという話なんだろうなぁ。公共機関は予算消化の意味で高く買ってくれるし、潰れないし、金は払う(サイトは長いらしいが)から、ええこと尽くめ。 WebのUIを作るのはとても苦手 コー
突撃！隣の開発環境 パート7【永和システムマネジメント編】 ｜ DevelopersIO
こんにちは！おおはしりきたけです。パート7の今回は、アジャイル開発で受託開発を行ったり、アジャイルのコーチングやidobataというグループチャットアプリなどの開発も行っている永和システムマネジメントのアジャイル事業部にお邪魔しました。インタビューに答えてくださったのは、Idobataエンジニアの寺田さんと、受託開発でエンジニアをやられている松島さんです。 突撃！隣の開発環境とは 技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開発体制なども技術領域によっても変わってくると思
Mac の開発環境構築を自動化する (2015 年初旬編) - t-wadaのブログ
背景 愛用していた MBP15" が一ヶ月ほど前に突然亡くなり、急遽 MBP13" を買って環境構築を行ったので記録しておく。 (その後噂の薄くて軽くて新しい Macbook が出ただけでなく MBP13" までマイナーアップデートされたりしたが、悔しくはない。悔しくはないぞ！！) Brewfile オワコン問題 開発環境の構築は Homebrew と Homebrew Cask を入れて Brewfile を書き、 brew bundle すれば終わりかと思いきや、もう Brewfile はオワコンになってしまったらしい。 (3/25 追記) Brewfile がオワコンなのではなく Homebrew 本体から bundle コマンドが外されただけで、 元となった brewdle コマンドは健在で、もっと便利な brew-file もあるとのことです。 参考: Brewfileはオワコン
いつも受け入れられるとは限らない改善提案: 柴田 芳樹 (Yoshiki Shibata)
社会人となって30年間、様々なソフトウェア開発従事していた経験から言うと、改善提案は上位のマネージャや部門長に受け入れられる場合とそうでない場合があります。その中でも、問題が発生してから、その問題を解決するという改善提案は受け入れられることが多いです。しかし、発生するであろう問題を予測して、それに対して事前に対策を打つという改善提案は、理解されなくて、受け入れらないことがあります。 問題が発生してからの改善としては、ソースコード管理用のリポジトリは用意していたが、開発の終盤までビルドは、一人の開発者のPCでしかできなくて、ビルドを間違いなく行う必要がでてきて、やっとサーバで自動ビルドが一日一回行われるとかです。さらに、コードの品質が悪くてバグがたくさん出るので、FindBugsなどの静的解析ツールを導入して改善しますと言った提案です。しかし、静的解析ツールを導入した時点ではすでに遅く、すべ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
