ショボいPull Requestを積み重ねて、自分の中でOSS活動の敷居を下げる - not good but great
GitHubのプロフィールページがパッとしない https://github.com/naoyashiga 「Repositories contributed to」がスカスカ GitHubの自分のプロフィールページを見るたびに、なんかパッとしないなあと思っていた。それは「Repositories contributed to」のところがスカスカだったからだ。Contributeをしてプロフィールページを豪華にしたいと思った。 スターが多いリポジトリは難しい できればスターが多いリポジトリにContributeしたい。自分はSwiftを使うことが多く、例えばAlamofireのような人気リポジトリに、プログラミング能力が低い自分がContributeするのは難しい。実際にリポジトリを見ても、何が問題なのか全くわからなかった笑 ショボいPull Requestを送る 「Repositorie
エンジニア経験無い人を教える＆働き先を紹介するまでの話 - 40歳からのキャリアチェンジ
タイトルで全て言い尽くしましたが、自分がやりたかった 教える（正確にはコーチング）⇔開発する の両方が相互に作用するような自分がイメージしてたことがようやく実を結びました！ Connecting the dots 1年前に書いたこのエントリで以下のTweet紹介してました @ukedchat @gapingvoid There's one more image to this that you're missing... creativity. :-) @ElsiumEd pic.twitter.com/T283tvkX30— Elsium (@DavidKirtlan) February 8, 2014 これ知ったのは増井さんの講演を紹介されてる記事なのですがそこで そして大事なのが、点と点を最短距離でつなげるだけでなく、異なる組み合わせをすることで、新しい全く考えもしなかった物が作れる
機会は自分で作る--フルスタック目指すならプログラミング5000時間
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回は、スキルがフルスタックに求められる背景、単一のスキルのみのエンジニアより、マルチなスキルを持つエンジニアが人気となる構図を説明した。そして、現場ですべてを素早く正確に遂行する「1人でなんでもやってくれる人」が「フルスタックエンジニア」として呼ばれる。“やってくれる”を大きくとらえると、以下のようなアクションの実行である。 機能やサービスレベルを理解し、複数案から最適なシステム構成を考えられる 各種手配をおこない、システム構築に必要なリソースを揃える 手を動かして環境を構築、プログラミングをし、システムを作り上げる 求められるレベルへ改良を重ねられる では、具体的に何のスキルをどれぐらいスタックすればよいのか。今回は若手エンジニアが
起業家が開発者のマネージメントで犯しやすい11の失敗 | readwrite.jp
ソフトウェア開発者達を育てるには、あなたのリーダーシップのスタイルを変える必要があるかもしれない。彼らは、一般的なマネジメントでは必ずしも輝かないのだ。何が一番重要か？前もってはっきりとした予測を立てる事、そして問題になる前に作業習慣の違いを考慮しておく事だ。 我々はYoung Entrepreneur Council （YECの11人の起業家達に、彼らが開発者を管理する上で経験したリーダーとしての大失敗と、同じ間違いを避けるためのコツを共有してもらった。彼らの回答は以下の通りだ。 彼らが意見を述べてくれると思い込む事ソフトウェア開発者達が自分の課題やアイディア、あるいは手柄についてさえも話してくれると思い込まない方が良い。多くの開発者達はチーム・ミーティングでこういった情報を進んでシェアしようとしない。開かれた、真摯なフィードバックは常にあなたから要求しなければならない。 自分の努力に対
仕様の決まる速度で実装する - mizchi's blog
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
