Redux Middleware Wars (Japanese)M3 Tech meetup! #2 ～フロントエンドの副作用～ http://m3-engineer.connpass.com/event/33802/
「プログラマとして食べていく」という話を福井県の学生さん達にしてきました - その後のその後
一昨日、福井県の「ふくい産業支援センター」さんが主催されたセミナーで、標題の講演をさせていただきました。資料はこちら。 参加者約70名のうち、75%は18歳以上の大学生・専門学校生、15%が高校生・高専生、10%が小中学校。これまでエンジニアの中で話をする機会は多々ありましたが、学生さんばかりの中で話すのは初めてでした。 内容 内容としては、「プログラミングでこんな感じでメシを食ってる人がいる」という一つの参考例として自分の働き方を紹介しつつ、プログラマとしてとりあえずやっていけるようになるまでの話と、フリーになってからおもしろい仕事を得るためにどんなことを考えながら働いているか、の3部構成でした。 50分と長尺の講演だったので、最後にFAQをくっつけて時間調整できるようにしておいたのですが、6つぐらい用意しておいたうち2つぐらいしかしゃべれず。話したうちのひとつは「お金の話」だったのです
開発チーム内の“宮大工”はこう活かせ～freeeの「巨匠システム」がいろいろ示唆深い - エンジニアtype | 転職type
エンジニアが働く上で気になる【開発環境】に焦点を当てた、チーム紹介コーナー。言語やツール類を紹介するだけではなく、チーム運営や開発を進める上での不文律など、ハード・ソフト面双方の「環境づくり」について深掘りしていく。 エンジニアのような専門スキルを武器に仕事をする人たちにとって、「スペシャリスト」は一度は憧れたことのあるポジションだろう。誰もが頭を悩ます課題をコードで解消し続け、周囲にすごい！と言わしめる。そんな仕事人生を全うできたら、これほど楽しいことはない。 海外の大手テクノロジー企業は各種スペシャリストを破格の待遇で雇う傾向がある一方で、日本企業では「スペシャリスト＝職権の限られた一専門職」扱いというところも。ビジネスそのものをけん引するのはディレクターやプロダクトオーナーであるとされ、収入面でも彼らの方がよかったりする（※参照記事）。 結果、経営者や開発チームのマネジャーは、「実力
ソースコードって実際のところどういうふうに書いていますか？｜Rui Ueyama
私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい
オープンソースなリアルタイムチャットシステム "respass" を3週間で作った - Sketchglass Blog
WebSocketを用いたオープンソースなリアルタイムチャットシステムrespassをリリースしました。 TL; DR 無職2人が3週間で https://respass.sketch-glass.io/ を作りました。 ソースコードはGitHub上で公開されています。 github.com 自己紹介 @minamorl 無職 Pythonエンジニア GitHub @seanchas_t 無職 C++/TypeScriptエンジニア GitHub はじめに この記事は主に技術者に向けて書かれていますが、そうでない方にも読めるような表現を重視しています。難解な用語にはなるべく注釈をいれました。技術的な話よりも「無職2人がいかにして3週間で作り上げたのか？」という開発フローの話に重きをおいたので、非技術者の方にも楽しく読んでいただけると思います。 なぜ作ったか オープンソースなチャット 近年、
Atomic Designの考え方と利点・欠点 – wkr.
Atomic Design はデザインシステムを作る方法論となります。 デザインシステムというのはスタイルガイドやブランドのガイドラインなどを指すようです。 日本だとAbemaTV（アベマ TV）で使われています。 （Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.comより） Atomic Design は今までのページ単位と違いコンポーネント単位でデザインカンプを作る考え方です。 作ったコンポーネント同士の組み合わせでページを作ります。 Atomic Design はコンポーネントの単位を 5 つに分けています。 その 5 つの単位は Atoms（原子）・Molecules（分子）・Organisms（有機体）・Templates（テンプレート）・Pages（ページ）です。 各コンポーネントの詳細は次のとおりです。
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
「おいしいですか？」という質問の模範解答
NISHIO Hirokazu @nishio @kmizu どういう回答を求めてそういう主観的な質問をしているのかよくわかりません。市販のレモングラスティーは目につくものは全部飲んだ上で、自家栽培を始めて二年目、というのが客観的な事実です。 2016-07-17 20:20:40
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
