弊社の新人エンジニア研修カリキュラムを惜しみなく公開してみる - Feedforce Developer Blog
こんにちは！今年の4月にポテンシャル枠で入社した id:daido1976 です！引き続き Rails に弄ばれる日々を過ごしています。 さて、今回は約4ヶ月間の新人エンジニア研修を受け終えた私が弊社の研修カリキュラムを公開し、まとめや実際に受けてみての感想を書いていきたいと思います。 前提として フィードフォースでは今年4月〜5月のほぼ同時期に e-Navigator というプログラムを通じて、私を含む3名の実務未経験エンジニアが入社しています。 今回の研修は、e-Navigator でもレビュアーだった @sukechannnn がメンターとして上記3名の新人エンジニアをフォローする体制で進めました！ 研修の成果を3行で 入社時に「プログラミング歴3ヶ月の超初心者エンジニア」だった私が フィードフォースで約4ヶ月間の新人エンジニア研修を受けて 配属後にある程度自走してコードが書けるぐら
python知識ゼロからポケモンの名前でしりとりするslackbotを作ったノウハウのすべて - Qiita
こんなのです ソースはgithubで公開してますhttps://github.com/wagase/pokeshiri よかったら「いいね」してください。 環境 OS：windows 言語：python 筆者について 趣味でプログラム書いてるにわか。 htmlとcssとjavascriptくらいはかける。 python知識ゼロ Twitterフォローされると喜びます https://twitter.com/wagase よろしくお願いします なぜpython？ 話題だから なぜslackbot？ 開発経験ゼロだから気軽に作れるのがよかった 開発環境構築 知識ゼロだからまずpythonという言語の仕様を学ぶ 参考にしたサイト https://www.pythonweb.jp/tutorial/ 斜め読みしながらわからないところはググる pythonをwindowsにインストール https:
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
Swiftコンパイラの構造と基盤テクニック - Qiita
はじめに Swiftのソースコードが公開されてから1週間以上が経ちましたが、意外にもまだSwiftコンパイラの構造を解説した日本語記事が少ないので、書いてみることにしました。 SwiftコンパイラはC++で書かれていますが、適切なモジュール化とコーディングスタイルの統一により、とても読みやすいものになっています。 ざっくりとしか解説しませんのでコミッターになれるほど詳細な仕様まではつかめませんが、今後Swiftの仕様がわからなくてソースコードを参照するときの参考や、そもそもコンパイラの構造自体に興味を持っている方の助けになれればと思います。 自分自身Swiftのコミッターというわけではなく、単に少しコンパイラについて学んだことがあるSwift好きという程度ですので、間違っている箇所などあればどしどしご指摘ください。 注意事項 この記事で対象としているソースコードのリビジョンは公開時のもの(
ランキング設計はどうあるべきか？ その3｜深津 貴之 (fladdict)
ここまでランキングのあるべき方向性と、実行可能なアプローチについて考察してきた。そして、いよいよプロトタイピングと実験の時間だ。残念ながら自分はサーバーサイドのコードが書けないので、ここからは開発チームに託すことになる。 妄想や実証不能なものをオーダーするのは非効率だと思う。ある程度はクラスをモデリングしておくと、エンジニアとディスカッションしやすい（ように思える）。 とりあえずnoteでのランキングは、様々な試行錯誤や実験が予想される。そのため、以下のような要素が必須となる。 ・工数最小 ・あらゆるランキングを表現できる ・拡張しやすい 今回はDecoratorパターンとCommandパターンを混ぜたような実装で、柔軟性のあるランキング計算システムのコンセプトを描いてみた。下手なコードでも、設計がある方がエンジニアさんに説明しやすい。 設計イメージとしては、まずランキングの各処理を同じイ
「書き直した方が早い」は9割のケースで間違いだった - 怠惰を求めて勤勉に行き着く
はじめに、本エントリは特定の企業、チーム、個人を指して書いたものでは一切ない。100%僕の個人的な経験から来ている。 さて、職業プログラミングに従事していると一度は「これ書き直した方が早いっす」とか言ったことある気がする。自分の場合、多くは歴史のあるレガシーコードを読んだときだ。思い返せば、自分がこう思ったときはほとんどそれは間違いであった。 「なんだこのコード…」 「これ何書いてあるか分かんないっす」 「うーんこれもう書き直した方が早くないっすか？」 この流れは非常に危険だ。 なぜならプログラムというのは本質的に書いてある通りにしか動かないからだ。ちゃんと読めば絶対に何を書いてあるかは分かる。 ここで安易に選んだ書き直しという選択は、自分が慣れ親しんだやり方でその部分をそっくり置き換えるというだけで、それは他人にとってあたらしい「これ何書いてあるかあるか分かんない」を生む結果にしかならな
「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama
自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの
よりよいネーミングを目指して / 20171003 #orecon_ios #akibaswift
俺コン Vol.1 / Day. 2 - connpass https://orecon.connpass.com/event/64285/ での発表資料です。 # 参考資料 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) | Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典 |本 | 通販 | Amazon https://www.amazon.co.jp/dp/4873115655 Amazon | 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES) | Martin Fowler, 児玉 公信, 友野 晶夫, 平澤 章, 梅澤 真史 通販 https://www.amazon.co.jp/dp/427405019X
iOS開発における環境変数の分け方
マンガZERO（iOS）の開発環境の紹介 マンガZERO（iOS）では環境変数をScheme毎に変えてビルドできるようにしています。 この記事では環境変数を変える理由と実際にConfigファイルを使って環境変数を切り替える手段を紹介します。 社内配布限定のアプリを作りたいなどの要望があった場合、この手法ですぐに対応できるようになるのでオススメです。 マンガZERO（iOS）のSchemeの分け方 以下の３パターンに分けてアプリを生成できるようにしています。 Debug 開発時用。開発者以外は触りません。 Adhoc 社内配布用。新機能の使い心地やユーザビリティなどを確かめる際に使われています。 社内ではFabricのBetaを使用して、配布しています。 Store 公開用。ストアに公開される状態をもつようにしています。 弊社ではiTunes ConnectのTestflightを使用して最
iOSの消耗型課金のサーバーサイドTipsまとめ - ZOZO TECH BLOG
こんにちは、バックエンドエンジニアのじょーです。 以前、月額課金型のサーバーサイドでのレシート検証の記事を書きました。(iOSの月額課金レシート検証をサーバーサイドで行うときのTipsまとめ) 今回は、消耗型課金のサーバーサイド実装について書きます！ 注意 この情報は2017年8月25日現在のものです。 目次 消耗型課金全体の処理フロー レシート検証について 課金アイテムの扱い方について 消耗型課金全体の処理フロー 消耗型課金とは、AppStoreで登録できる使い切りのアイテムへの課金のことをいいます。 たとえば、ゲームアプリでライフを購入するときなどは使い切りのアイテムなので消耗型課金になります。一方、1か月など決まった期間サービスが受けられる課金のことを月額課金や、自動更新購読といったりします。 (実際のアイテム登録画面) アプリで消耗型課金商品を購入してからの処理の順番は、下記の図の
MITライセンスを1行1行読んでいく | POSTD
全てのプログラマが理解すべき171語の文章 MITライセンス は、最も有名なオープンソースソフトウェアのライセンスです。この記事では、その内容を一行一行読んでいきます。 ライセンスを読む オープンソースソフトウェアを利用しているものの、これまでライセンス全文（原文：171語）を読む機会がなかった方は、大した量ではないので、今すぐ読んでください。あなたにとってライセンスが身近なものでないなら尚更です。理解できない箇所などがあれば、その部分は心に留めておき、明確にするようにしてください。これから背景や解説とともに、全文を分割して順番に紹介していきますが、大事なことは全容を頭に入れておくことです。 MITライセンス（MIT） Copyright (c) <年> <著作権保持者> 本ソフトウェアおよび関連文書ファイル（以下「ソフトウェア」）のコピーを入手する全ての人に対し、それらに関する無償のライ
動的計画法（ナップサック問題） - アルゴリズム講習会
動的計画法とナップサック問題について解説します。 動的計画法とは 直接計算すると大きな時間がかかってしまう問題に対し、途中の計算結果をうまく再利用することで計算効率を上げる手法のこと。 「途中の計算結果を再利用」＝「同じ計算をしない」ということ 難しいように見えて考え方自体は単純 ICPC国内予選でもC問題～F問題くらいに何かしらの形で2,3題ほどでます 英語では「Dynamic Programming」と呼び、略して「DP」と呼ぶことが多いです。 動的計画法で効率的に解ける問題の一つに、ナップサック問題というものがあります。 ナップサック問題は、価値と重さが決まっている複数の品物を容量が一定のナップサックに詰め込むとき、ナップサックに詰め込める品物の価値の和の最大値は何であるか？ という問題です。 具体的には、以下の図のようになります。ナップサックに書かれている「15kg」が容量で、周囲
Protocol Extensionsのwhere句を使ってTraitを実現し、BaseViewControllerを排除する
iOSアプリの開発において共通処理をBaseViewController(仮)のような親クラスに定義して、 各画面はこの親クラスを継承するといった実装がわりとあるかなと思います。 このような実装の場合、BaseViewControllerが肥大化して、見通しの悪い設計になりがちです。 また、独自フレームワークのような実装になってしまう傾向があり、 チーム開発においては、メンバーの学習コストが上がるなどのデメリットがあります。 その一方、各viewControllerに共通で入れたい処理というのはあるので、 そういった場合は、Protocol ExtensionsのWhere句を利用してTraitを実現するといいなと考えています。 例えば、UIActivityViewControllerを使って、データを共有する処理を共通化する場合 BaseViewControllerを利用した実装は下記の
codic - デベロッパーのためのネーミング辞書
codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。
全てのApple Storeで、12月5日-11日に「Hour of Code」の無料ワークショップを開催 | Apple Store | Mac OTAKARA
※本サイトは、アフィリエイト広告および広告による収益を得て運営しています。購入により売上の一部が本サイトに還元されることがあります。 Appleが、Hour of Codeの無料ワークショップを12月5日-11日に全てのApple Storeで開催すると発表しています。 コンピュータサイエンス教育週間(Computer Science Education Week)を祝して実施するHour of Codeワークショップの受講登録を、世界全487店舗のApple Storeで開始するそうです。 コンピュータサイエンスの基礎をCode.org提供のプログラミング教材を用いて学ぶことができます。 AppleならびにCode.orgは、あらゆる学生がコンピュータサイエンスを学ぶ機会を提供するという共通の目的を掲げているそうです。
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
Fitbitから取得した心拍データで時系列の異常検知を試してみる - About connecting the dots.
井出先生の「異常検知と変化検知」を読んで，自分でも試してみたいと思ったんですが，あいにくちょうどいい時系列データが手元にないなーと思ってました．そんな折，データサイエンスLT祭りの発表の中に，Fitbitデータを可視化するものがあって*1，これはちょうどいいということで試してみましたよというていのエントリになります． 異常検知と変化検知 (機械学習プロフェッショナルシリーズ) 作者: 井手剛,杉山将出版社/メーカー: 講談社発売日: 2015/08/08メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る Fitbitってなによ Fitbitが何かしらない人のために一応説明しておくと，最近はやりの活動量計です．私が持っているのは，心拍が取得できるタイプのやつです．風呂に入るとき以外は一日中つけっぱなしで，睡眠とか運動とかを自動で判定してくれるので，手間がかからず便利です
O'Reilly Media - Technology and Business Training
More than 5,000 organizations trust O’Reilly to help their teams learn the technologies of today—and be ready for what’s next. We can help yours too. It’s time to upskill your teams to leverage generative AI LLMs aren’t just the future of work—they’re the now. Learning to use large language models is vital for every business and every knowledge worker. O’Reilly has all the resources your team need
全く新しい銀行を１から作るために必要な技術 （Monzo公式ブログより） - Qiita
あらまし 今年（2016年）８月１０日、イギリスで全く新しい銀行が誕生しました。 イギリスの金融当局、PRA が、「Monzo Bank Ltd」を制限付きで認可。２０１５年２月に設立以来、別のカード会社と提携してプリペイドカードを発行し、その利用状況をスマホ等で即時に確認できるサービスを限られた顧客に提供してきましたが、これから当局との調整を進め、２０１７年前半を目処に銀行としての業務を開始すべく準備を進めるとのことです。 技術要素 過去にUberの競合であるHailoや、イギリスのオンラインカラオケサービス等でエンジニアを務め、現在 Monzo の Head of Engineering である Oliver Beattie氏が、公式ブログで「Building a Modern Bank Backend」と題し、技術要素についての説明をしているので、その内容を簡単に紹介します。 マイク
すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
