タグ

programmingとdevelopmentに関するkenjiro_nのブックマーク (79)

  • 株式会社リクルート エンジニアコース新人研修の内容を公開します!(2021年度版) | Recruit Tech Blog

    こんにちは! Webフロントエンドエンジニアの眞野 隼輔です。 毎年大きな反響を頂いている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートでは、エンジニアコースでスペシャリスト採用された新卒のエンジニアを対象に、現場で培われた「当に必要な生きた知識・技術」を取り入れた新人研修を開催しています。 前半は研修では各分野に長けた社員による講義形式の技術研修を行い、後半は仮配属という形でそれぞれ別の部署に配属されて実際の業務を経験するOJTとなっています。 この技術研修はそのほとんどが内製されており、ベテラン社員による経験を元にした講義を通して生きた知識・技術を獲得できます。また、実際に手を動かす演習型の講義ではベテラン社員からのレビューやフィードバックを得られるため、知識の定着や更なる成長へと繋がります。 年度の技術研修も、昨年度に引き続きフルリモートでの

    株式会社リクルート エンジニアコース新人研修の内容を公開します!(2021年度版) | Recruit Tech Blog
    kenjiro_n
    kenjiro_n 2022/09/15
    やじうまWatchの記事で2022年分とともに紹介されていた。
  • 株式会社リクルート エンジニアコース新人研修の内容を公開します!(2022年度版)

    こんにちは!2022年度エンジニア新人の太田です。毎年反響を頂いているエンジニアコースの研修内容を、今年は受講者の立場から紹介させていただきます。 研修概要 リクルートの新卒エンジニアコースでは、入社した新人を対象に技術研修を行っています。その内容は、実際の開発業務に活かせる技術を扱う「当に必要な生きた知識・技術」を取り入れたものとなっています。 特筆すべき点として、研修の資料はほとんどが内製であることが挙げられます。そのため、講義中の質疑を通してより深い知識や、開発の現場で培われた経験に触れることができます。 フロントエンド、モバイルアプリ、バックエンド、インフラ、データ分析セキュリティなど幅広いテーマが扱われるため、知識のインデックスを張ることにもつながります。またハンズオンや競技形式の演習も取り入れられており、実際に手を動かすことで印象に残りやすく、エラーへの対処も学ぶことができ

    株式会社リクルート エンジニアコース新人研修の内容を公開します!(2022年度版)
  • 「正直9年経ったいまでもfor文ググってる」 - Qiita

    「正直9年経ったいまでもfor文ググってる」 という議論記事があった。正直なところ私もググる方の人だ。私の感想: ポンとテキストエディタだけ渡された時に書けるか自信ないぞ...IDEがあればまあ大丈夫かなあ。 JavaScriptだけじゃない。言語色々扱うしという言い訳。正規表現とか毎度調べる。 だから世の中にチートシートというものがあるのだ。お気に入りチートシート多数。 実戦でどうしているか?結局周りのソースを見て馴染む書き方にしていますよ多分。 暗記するかしないかは受験勉強みたいなもので、コーディング面接に受かるなら必要。暗記そのものには意味はないとは思う。 競技プログラミングが使えないとかいう論もあったな。 ググり力も大事。 でも「最低限」もできないのはやはり恥ずかしい気持ちはある。 なんかこれ英語できるできないと似てるな。英語なんてGoogle翻訳、DeepL翻訳あればいいけど、実

    「正直9年経ったいまでもfor文ググってる」 - Qiita
  • 技術的に難しいことを力技でやってしまうこと - orangeitems’s diary

    まあお悩みですけどね、技術的に難しいことってありますよね。で、他のメンバーに任せておくと、いつ終わるかわからない。聞いてもわからんわからんばかりで、こりゃダメだと言う時のことです。 いつものように、それ私が引き取るよ、ってその課題を引き取って、難易度の低いタスクを他のメンバーに任せます。まあそのタスクも大量なので、誰かがやらなきゃいけないし、高度な問題のために大量のタスクが積みあがるのもそれはそれでまずい。適材適所と言えばそうなのですが、当にこれでいいのかなと毎回思います。 だって、またこの高度な問題に対するトラブルシューティングを見ることなく、メンバーは最終的に「できた」という形を手順書なりなんなりで確認することになります。ああこうやればできたのか、という感動があればまだいいですが、忙しいのでそんなことしている暇は多分ありません。 これ、私はまたスキルを一つ積み上げたのですが、どう考え

    技術的に難しいことを力技でやってしまうこと - orangeitems’s diary
  • 2020年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。コネクト支援チームの@tignyaxです。 みなさま、夏はどう過ごされたでしょうか? 私は、夏が好きなのに今年は夏らしいことが出来なくて寂しいなぁとなっています。。。 さて、今年2020年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2020年のエンジニア新人研修について 基的には2019年と同じ形*1での実施となりました。 最初の1週間で必修講義をしたあと、新人の皆さんには2週間ずつ3チームを体験してもらいました。 チーム体験のコンセプトは、新人に「興味のあるチームで実際に業務を体験し、配属希望を決める参考になった。」と言ってもらうことです。 各チーム体験では座学や研修を中心にするのではなく、業務体験が中心です。 チーム体験を通して、配属先を検討する材料にしたり、いろんなチーム/人/業務を知ってもらえる機会となります。 必修講義 誰に: 開発/

    2020年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
  • clocとシェルスクリプトでgit管理ソースの改修ステップ数を集計 - Qiita

    やりたいこと 世の中にはソースコードの行数を知りたがる人がいます。 Gitリポジトリから詳細なステップ数を取得するツールとしてclocがあり、これだけで十分便利なのですが、一部のファイルはカウントから除外するとか、全体のステップ数と改修分のステップ数を出すとか、コメントを含めないのと含めたのとそれぞれ合算するとか、細かい集計を毎回手作業でやるのは地味に面倒です。 というわけで、シェルでJSONをいじる練習も兼ねて自動化してみました。 アウトプットイメージ 最終的にこんなものを作ります。 行単位で、追加されたものを「追加」、変更されたものを「修正」、変更のないものを「流用」としてカウントします。 実行環境 Windows 10 PC的にはLinuxでもできることしかやらないので、CI環境にもっていくこともできると思います git git bash(シェルの実行環境) cloc cloc

    clocとシェルスクリプトでgit管理ソースの改修ステップ数を集計 - Qiita
  • コードレビューで「違和感」という言葉を使わない - okuzawatsの日記

    雑感です。カップ麺ができるまでに書き散らします。 コードレビューをする時、「違和感がある」というような言葉を使わないようにしています。「違和感がある」という言い方は便利なのですが、何がどうダメなのかを言っていないため、それをレビュイーに考えさせ、余計なコミュニケーションを取ることになる気がしているためです。 そのため、「違和感がある」というようなレビューをしそうになったときには、何についてどのような違和感があるのかを言語化して、具体的なコメントをするようにした方が良いと思います。 雑な例(適当に考えました): before この処理をこのクラス内で行うのは違和感があります after このクラスの責務はhogefugaなので、この処理は新たにFooClassを作ってそちらで行うようにした方が良いと思います そろそろカップ麺ができるので、この辺で失礼します。

    コードレビューで「違和感」という言葉を使わない - okuzawatsの日記
  • プログラム開発者格差の話をしよう - Qiita

    Help us understand the problem. What is going on with this article? 先日、とある記事が削除された。 数時間の寿命だったのでご存じない方もいると思うので、つかみだけ紹介しよう。 簡単に言うと、Unityの有志開発ライブラリ、UniRxについての記事だ。 企業プロジェクトでUniRxを気軽に採用すると地獄だぞ、という内容だった。 そしてこの記事が削除された理由は、コメント欄に 「それ全部あんたのチームの問題であって、UniRxの問題ではなくない?」 という趣旨の反論、批判が発生したからである。 彼らの言い分はこうだ。 技術力が低い人間が高等な武器を手にしても自爆スイッチ押すだけだ、と。 なので、技術力を身に着けてから着手すべきだし、追加人員も教育してから実戦投入しろと。 ■ さて、この発言そのものは真理である。 チームの全員が

    プログラム開発者格差の話をしよう - Qiita
    kenjiro_n
    kenjiro_n 2020/03/14
    今日のおまおれ発言をすることになりそうだったが結論が「見捨てろ」という話だったので同意できなかった。俺の場合は相手が自社の若手だという事情もあるのだけれど。/ガイドライン違反で非公開措置になってた。
  • リモート・モブプログラミングという働き方 - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは!kintone開発チームの太田 (@kigh) です。 この記事では、自分のチームで2年以上続けているリモート・モブプログラミング(以下「リモート・モブ」)について、 進め方の具体例や所感、実際にやる上でのTipsを紹介したいと思います。 リモートワークが急速に普及する中、リモート・モブは働き方の選択肢の一つとして存在感を増してきていると思います。 この記事から少しでも参考になる点が見つかれば幸いです。 リモート・モブプログラミング この記事では、テレビ会議システムなどのツールを使いつつ、物理的に離れたチームでモブプログラミングをすることをリモート・モブと呼びます。 現在、kintoneの新機能開発メンバーは6拠点のオフィスに分散し、また多くのメンバーがカジュアルに在宅勤務を活用するリモートチームとなっています。 また2018年から2年以上、全ての設計・実装タスクを原則モブプロ

    リモート・モブプログラミングという働き方 - Cybozu Inside Out | サイボウズエンジニアのブログ
  • 10年でどう変わった? はてなブックマークでのPerlの使い方

    2019-11-03 YAPC::Nagoya::Tiny 2019 https://yapcjapan.connpass.com/event/146727/

    10年でどう変わった? はてなブックマークでのPerlの使い方
  • WeChat mini program (微信小程序)の開発環境を構築する - Qiita

    はじめに WeChat(微信)とは、中国を中心に使用されているメッセージングサービスです。「中国LINE」とざっくり説明されることがあります。 WeChat mini program(微信小程序)とは、WeChat上に構築できるウェブサイト/アプリの・ようなものです。 Canvasや通常のhtmlタグを使った画面表示、メディア録画・再生、マップ表示、WeChatのログイン及びペイメントとの連携、ストレージアクセスなどができるようです(まだ全部試せていない)。 この記事では、WeChat mini programの開発環境の構築のしかたを説明します。具体的なコーディング方法については記載されていません。 開発言語はJavaScript, wxml(html方言), wxss(css方言)です。 丸いやつがmini programです。 こんな感じに各社mini programをリリースして

    WeChat mini program (微信小程序)の開発環境を構築する - Qiita
  • プログラマーを30年間やってきた経験から学んだことまとめ

    プログラマーにとって「どうすればより効率よくプログラムを組み上げられるのか」は常に頭を悩まし続ける問題の1つとなっていますが、その道のエキスパートであるエンジニアのジュリオ・ビアソンさんが30年間ソフトウェア開発に携わってきた経験から学んだことについてブログにまとめています。 Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development) https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/ ビアソンさんは多数ある「学んだこと」を以下の3つに大きくわけてまとめています。 ◆ソフトウェア開発について ◆チーム・仕事について ◆個人的なことについて これからプログラマーになろうとしている、あるいは

    プログラマーを30年間やってきた経験から学んだことまとめ
  • [PDF]COBOL資産を活用した .NETによる 名鉄時刻表検索システム構築事例

    kenjiro_n
    kenjiro_n 2019/03/20
    既存コード資産を考えるとしょうがないのだろうけど、10ページ以降のVB.netからCOBOLを呼び出すシステムという記述を見てざらついた感覚を覚えてしまった。
  • 学べず成長機会が乏しい、IT職場に高まる不満

    「学習機会がない」「社内にノウハウがたまらない」──。あるIT職場で実施した社員の満足度調査に寄せられた、若手からの辛辣なコメントである。 企業が実施する従業員満足度調査で、この2つを会社に対する不満として挙げる人は少なくない。IT職場も例外ではなく、名だたる大企業でもこんなネガティブな意見を頻繁に見かけるという。 「誰もが知っている有名企業のIT職場には、先人の知恵や洗練された業務プロセスが確立されていて、しかも大きな仕事や新しいチャレンジができる」。そう意気込んで入社してきた若手が目の当たりにする現実の景色は、想像とは全く違うものだった。例えば、こんなふうに。 属人化したノウハウや勘で業務を回している 誰に何を聞いたらいいのか分からない 毎回、自分でゼロから考えて走るしかない 最後に求められるのは気合と根性 入社前に抱いていたIT職場のイメージとの大きなギャップに、新人や中途入社の社員

    学べず成長機会が乏しい、IT職場に高まる不満
  • コンピュータシステムのサマータイム対応を巡る二つの楽観論 - アンカテ

    いきなり来年から日でサマータイムを導入するという話が出てきて、私には到底実現できない話としか思えなかったが、自民党の少なくとも一部の方々は気で考えているようだ。そもそも、私にはメリットがどこにあるのかわからないがそれは置いておいて、コンピュータシステム側の対応が非常に困難であるということを、なるべく一般の方にわかるように説明してみたいと思う。 5chとツィッターを眺めて見ると、同業者の人は私と同じ意見が多数であるように見えるが、一部楽観的に見ている方もいるのに驚いた。何事にもいろいろな見方があるので、賛否両論の意見があって議論していけばいいことではあるが、その楽観論を見ていると、全く違う立場の二種類の楽観論がある。何がなんでも自分の立場が正しいと主張する気はないが、この二種類の楽観論が絶対両立しないことは確かで、ここだけはハッキリしておかなければならないと強く言いたい。 最悪のケースは

    コンピュータシステムのサマータイム対応を巡る二つの楽観論 - アンカテ
  • エンジニアは業務時間外でも勉強するべきなのか | 株式会社アクシア

    エンジニアがスキルアップするための勉強を業務時間外でもするべきかどうかについて、「教育してエンジニアを育てるのは企業側の責任だ」「エンジニアであればスキルアップのために当然自分で勉強すべきだ」といったような議論を度々見かけます。 この問題についてはどちらが正解というわけでもないかもしれませんし、企業やエンジニアのポリシーによるところも大きいかもしれません。 いずれにしても今後うちの会社の求人に応募してきてくれる方に向けて、企業として、または会社トップとしての私の考えを明確にしておくことはやっておいた方が良いなと思いましたので、この記事に私の考えをまとめてみたいと思います。 プライベートで勉強しなくても何とかなります 仕事をこなしていくという観点から言えばプライベートでの勉強を一切やらなくても何とかなります。たとえ未経験で入社してきた人であってもそれくらいの教育は行っています。 でも最初にこ

    エンジニアは業務時間外でも勉強するべきなのか | 株式会社アクシア
    kenjiro_n
    kenjiro_n 2017/07/19
    「私は勉強意欲のない人には1分も業務時間での勉強時間は与えません。」と切り捨てている。勉強意欲を育成する方法というものをどうにかしたいとも考えているがその具体案を考えあぐねている。
  • コメントの9割は無駄!~アンチプラクティスから学ぶ洗練されたコメントの書き方~ #code #コード|CodeIQ MAGAZINE

    コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 (CodeIQ中の人) コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする

    コメントの9割は無駄!~アンチプラクティスから学ぶ洗練されたコメントの書き方~ #code #コード|CodeIQ MAGAZINE
  • 開発基盤チームが目指す事 #pixiv_night - Qiita

    (当日はesaのプレゼンテーションモードで発表しました) (pixiv night in Fukuoka #02 - ピクシブを取り巻く技術がわかる一夜! - connpass の発表資料です) 自己紹介 各種SNSをcatatsuyでやっている かたついと呼ばれることが多い ピクシブ株式会社で開発基盤チームと広告チームの兼任 2014年度新卒(2013/10入社) pixiv技術的な改善が主な業務(後で詳しく) 単著『pixivエンジニアが教えるプログラミング入門(星海社新書) ピクシブ社内の非エンジニア向けのプログラミング研修の書籍化 pixiv社内ISUCONやISUCON6選の問題作成 pixivのチーム分け pixivというサービスは巨大 www.pixiv.net/touch.pixiv.net/スマートフォン用APIなどなど 提供しているサービスも多い pixivという1

    開発基盤チームが目指す事 #pixiv_night - Qiita
  • OneNote add-ins documentation - Office Add-ins

    This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

    OneNote add-ins documentation - Office Add-ins
  • 最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;

    コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの

    最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;