タグ

関連タグで絞り込む (21)

タグの絞り込みを解除

programmingとteamに関するhidex7777のブックマーク (8)

  • エンジニア経験無い人を教える＆働き先を紹介するまでの話 - 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 これ知ったのは増井さんの講演を紹介されてる記事なのですがそこで そして大事なのが、点と点を最短距離でつなげるだけでなく、異なる組み合わせをすることで、新しい全く考えもしなかった物が作れる

    エンジニア経験無い人を教える＆働き先を紹介するまでの話 - 40歳からのキャリアチェンジ

  • 会社でjQuery使ったら無能上司に怒鳴られたんだがｗｗｗｗｗ : IT速報


    1: 仕様書無しさん 2014/09/22(月) 12:19:06.02 .net jqueryで書いてたら怒鳴られた うちでは使うなって・・・こっちのが簡単じゃん・・・なんで書けないの 3: 仕様書無しさん 2014/09/22(月) 13:47:22.65 .net 世の中には馬鹿で無能な会社もあるってことよ。 15: 仕様書無しさん 2014/09/22(月) 20:16:36.27 .net ゴミのような上司だな。 もしシステム屋なら直ちに転職しろ。 6: 仕様書無しさん 2014/09/22(月) 15:25:28.97 .net >>1新人かい？ なんで使ったらいけないのか理由を聞きな。 納得できたなら使わなければいいし、納得出来ないなら説得してみればいい。 説得して無理なら、諦めるか配置換え希望出すか転職するか。 12: 仕様書無しさん 2014/09/22(月) 18:3
    会社でjQuery使ったら無能上司に怒鳴られたんだがｗｗｗｗｗ : IT速報
    hidex7777
    hidex7777 2015/02/11
    これはひどい
    リンク

  • ソフトウェア開発時に気をつけてる振る舞い - futoase


    他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、﹁変更した理由﹂と﹁変更して欲しい意図﹂を説明する。 その前に一言、﹁修正﹂とかチケットで﹁修正﹂とつけてはいけない。 その人は﹁変更前の仕様﹂を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても﹁気が付かなかったフリ﹂をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
    ソフトウェア開発時に気をつけてる振る舞い - futoase

  • 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログ


    独学でプログラミングを勉強してIT業界に就職したけど、やはり独学で得た技術だけだと通用しないと思う局面が幾たびもあった。 今は本はたくさん出てるし、動画もあるし、生のコードを読みたければGitでいくらでも読めるし、独学で勉強する土台はかなりできていると思う。 それでもなかなか実務に通用しない。 その理由はいろいろあるんだけど、自分が強く感じた3つの理由をこの記事では挙げたい。1．独学では妥協をいくらでもできる 独学で作っているプログラムだと、使い勝手が悪い機能を見つけたとしても﹁ま、ええか﹂で済ませてられてしまう。 誰に命令されて作っているわけでもないから。極端な話、バグがあっても放置できる。﹁小さいバグだしいいでしょ﹂と。実務でそれをやったら殺される。 ﹁ま、めんどくさそうだしこれでええか﹂で済ませてしまうと、めんどくさい実装をすることで得られる技術の向上がなくなる。 実際、現場だと仕
    独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログ

  • 初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita

    pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書

    初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita

  • 眼鏡なしのコードレビュー | POSTD


    例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか?家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか？ そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード1不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一
    眼鏡なしのコードレビュー | POSTD

  • はてなブログチームの開発フローとGitHub

    6/1 github kaigi

    はてなブログチームの開発フローとGitHub

  • レビュータイムの導入・消滅・再導入 - $shibayu36->blog;


    今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
    レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.