タグ

programmingに関するstiloのブックマーク (176)

  • 弊社の新人エンジニア研修カリキュラムを惜しみなく公開してみる - Feedforce Developer Blog

    こんにちは!今年の4月にポテンシャル枠で入社した id:daido1976 です!引き続き Rails に弄ばれる日々を過ごしています。 さて、今回は約4ヶ月間の新人エンジニア研修を受け終えた私が弊社の研修カリキュラムを公開し、まとめや実際に受けてみての感想を書いていきたいと思います。 前提として フィードフォースでは今年4月〜5月のほぼ同時期に e-Navigator というプログラムを通じて、私を含む3名の実務未経験エンジニアが入社しています。 今回の研修は、e-Navigator でもレビュアーだった @sukechannnn がメンターとして上記3名の新人エンジニアをフォローする体制で進めました! 研修の成果を3行で 入社時に「プログラミング歴3ヶ月の超初心者エンジニア」だった私が フィードフォースで約4ヶ月間の新人エンジニア研修を受けて 配属後にある程度自走してコードが書けるぐら

    弊社の新人エンジニア研修カリキュラムを惜しみなく公開してみる - Feedforce Developer Blog
  • python知識ゼロからポケモンの名前でしりとりするslackbotを作ったノウハウのすべて - Qiita

    こんなのです ソースはgithubで公開してますhttps://github.com/wagase/pokeshiri よかったら「いいね」してください。 環境 OS:windows 言語:python 筆者について 趣味でプログラム書いてるにわか。 htmlcssjavascriptくらいはかける。 python知識ゼロ Twitterフォローされると喜びます https://twitter.com/wagase よろしくお願いします なぜpython? 話題だから なぜslackbot? 開発経験ゼロだから気軽に作れるのがよかった 開発環境構築 知識ゼロだからまずpythonという言語の仕様を学ぶ 参考にしたサイト https://www.pythonweb.jp/tutorial/ 斜め読みしながらわからないところはググる pythonwindowsにインストール https:

    python知識ゼロからポケモンの名前でしりとりするslackbotを作ったノウハウのすべて - Qiita
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
    stilo
    stilo 2018/04/06
    『自分が良いと思うデザインで小さくて実際に動くものを作り、それを次第に育てていくことが大切だ。』
  • Swiftコンパイラの構造と基盤テクニック - Qiita

    はじめに Swiftのソースコードが公開されてから1週間以上が経ちましたが、意外にもまだSwiftコンパイラの構造を解説した日語記事が少ないので、書いてみることにしました。 SwiftコンパイラはC++で書かれていますが、適切なモジュール化とコーディングスタイルの統一により、とても読みやすいものになっています。 ざっくりとしか解説しませんのでコミッターになれるほど詳細な仕様まではつかめませんが、今後Swiftの仕様がわからなくてソースコードを参照するときの参考や、そもそもコンパイラの構造自体に興味を持っている方の助けになれればと思います。 自分自身Swiftのコミッターというわけではなく、単に少しコンパイラについて学んだことがあるSwift好きという程度ですので、間違っている箇所などあればどしどしご指摘ください。 注意事項 この記事で対象としているソースコードのリビジョンは公開時のもの(

    Swiftコンパイラの構造と基盤テクニック - Qiita
  • ランキング設計はどうあるべきか? その3|深津 貴之 (fladdict)

    ここまでランキングのあるべき方向性と、実行可能なアプローチについて考察してきた。そして、いよいよプロトタイピングと実験の時間だ。残念ながら自分はサーバーサイドのコードが書けないので、ここからは開発チームに託すことになる。 妄想や実証不能なものをオーダーするのは非効率だと思う。ある程度はクラスをモデリングしておくと、エンジニアとディスカッションしやすい(ように思える)。 とりあえずnoteでのランキングは、様々な試行錯誤や実験が予想される。そのため、以下のような要素が必須となる。 ・工数最小 ・あらゆるランキングを表現できる ・拡張しやすい 今回はDecoratorパターンとCommandパターンを混ぜたような実装で、柔軟性のあるランキング計算システムのコンセプトを描いてみた。下手なコードでも、設計がある方がエンジニアさんに説明しやすい。 設計イメージとしては、まずランキングの各処理を同じイ

    ランキング設計はどうあるべきか? その3|深津 貴之 (fladdict)
  • 「書き直した方が早い」は9割のケースで間違いだった - 怠惰を求めて勤勉に行き着く

    はじめに、エントリは特定の企業、チーム、個人を指して書いたものでは一切ない。100%僕の個人的な経験から来ている。 さて、職業プログラミングに従事していると一度は「これ書き直した方が早いっす」とか言ったことある気がする。自分の場合、多くは歴史のあるレガシーコードを読んだときだ。思い返せば、自分がこう思ったときはほとんどそれは間違いであった。 「なんだこのコード…」 「これ何書いてあるか分かんないっす」 「うーんこれもう書き直した方が早くないっすか?」 この流れは非常に危険だ。 なぜならプログラムというのは質的に書いてある通りにしか動かないからだ。ちゃんと読めば絶対に何を書いてあるかは分かる。 ここで安易に選んだ書き直しという選択は、自分が慣れ親しんだやり方でその部分をそっくり置き換えるというだけで、それは他人にとってあたらしい「これ何書いてあるかあるか分かんない」を生む結果にしかならな

    「書き直した方が早い」は9割のケースで間違いだった - 怠惰を求めて勤勉に行き着く
    stilo
    stilo 2018/01/16
    『ここで取るべき行動は、注意深く辛抱強くコードを読み、解きほぐし、リファクタリングすることだ。「何書いてあるか分かるまで」書き直すなんて言えないはずだ。』
  • 「プログラミングの常識」を時々見直す必要性について|Rui Ueyama

    自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上のの開いているページを見るのと、そのAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

    「プログラミングの常識」を時々見直す必要性について|Rui Ueyama
    stilo
    stilo 2017/11/03
    『昔の常識は今の常識ではないし、今の常識は未来の常識でもない。常にどういうバランスでプログラムを書くのがよいのか自分の中で調整していくことが大切だ。』
  • よりよいネーミングを目指して / 20171003 #orecon_ios #akibaswift

    俺コン Vol.1 / Day. 2 - connpass https://orecon.connpass.com/event/64285/ での発表資料です。 # 参考資料 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practic…

    よりよいネーミングを目指して / 20171003 #orecon_ios #akibaswift
    stilo
    stilo 2017/10/04
    とてもよい参考になりました。
  • iOS開発における環境変数の分け方

    マンガZERO(iOS)の開発環境の紹介 マンガZERO(iOS)では環境変数をScheme毎に変えてビルドできるようにしています。 この記事では環境変数を変える理由と実際にConfigファイルを使って環境変数を切り替える手段を紹介します。 社内配布限定のアプリを作りたいなどの要望があった場合、この手法ですぐに対応できるようになるのでオススメです。 マンガZERO(iOS)のSchemeの分け方 以下の3パターンに分けてアプリを生成できるようにしています。 Debug 開発時用。開発者以外は触りません。 Adhoc 社内配布用。新機能の使い心地やユーザビリティなどを確かめる際に使われています。 社内ではFabricのBetaを使用して、配布しています。 Store 公開用。ストアに公開される状態をもつようにしています。 弊社ではiTunes ConnectのTestflightを使用して最

    iOS開発における環境変数の分け方
  • iOSの消耗型課金のサーバーサイドTipsまとめ - ZOZO TECH BLOG

    こんにちは、バックエンドエンジニアのじょーです。 以前、月額課金型のサーバーサイドでのレシート検証の記事を書きました。(iOSの月額課金レシート検証をサーバーサイドで行うときのTipsまとめ) 今回は、消耗型課金のサーバーサイド実装について書きます! 注意 この情報は2017年8月25日現在のものです。 目次 消耗型課金全体の処理フロー レシート検証について 課金アイテムの扱い方について 消耗型課金全体の処理フロー 消耗型課金とは、AppStoreで登録できる使い切りのアイテムへの課金のことをいいます。 たとえば、ゲームアプリでライフを購入するときなどは使い切りのアイテムなので消耗型課金になります。一方、1か月など決まった期間サービスが受けられる課金のことを月額課金や、自動更新購読といったりします。 (実際のアイテム登録画面) アプリで消耗型課金商品を購入してからの処理の順番は、下記の図の

    iOSの消耗型課金のサーバーサイドTipsまとめ - ZOZO TECH BLOG
  • MITライセンスを1行1行読んでいく | POSTD

    全てのプログラマが理解すべき171語の文章 MITライセンス は、最も有名なオープンソースソフトウェアのライセンスです。この記事では、その内容を一行一行読んでいきます。 ライセンスを読む オープンソースソフトウェアを利用しているものの、これまでライセンス全文(原文:171語)を読む機会がなかった方は、大した量ではないので、今すぐ読んでください。あなたにとってライセンスが身近なものでないなら尚更です。理解できない箇所などがあれば、その部分は心に留めておき、明確にするようにしてください。これから背景や解説とともに、全文を分割して順番に紹介していきますが、大事なことは全容を頭に入れておくことです。 MITライセンス(MIT) Copyright (c) \<年> \<著作権保持者> ソフトウェアおよび関連文書ファイル(以下「ソフトウェア」)のコピーを入手する全ての人に対し、それらに関する無償の

    MITライセンスを1行1行読んでいく | POSTD
  • 動的計画法(ナップサック問題) - アルゴリズム講習会

    動的計画法(ナップサック問題) 動的計画法とナップサック問題について解説します。 動的計画法とは 直接計算すると大きな時間がかかってしまう問題に対し、途中の計算結果をうまく再利用することで計算効率を上げる手法のこと。 「途中の計算結果を再利用」=「同じ計算をしない」ということ 難しいように見えて考え方自体は単純 ICPC国内予選でもC問題~F問題くらいに何かしらの形で2,3題ほどでます 英語では「Dynamic Programming」と呼び、略して「DP」と呼ぶことが多いです。 動的計画法で効率的に解ける問題の一つに、ナップサック問題というものがあります。 ナップサック問題 ナップサック問題は、価値と重さが決まっている複数の品物を容量が一定のナップサックに詰め込むとき、ナップサックに詰め込める品物の価値の和の最大値は何であるか? という問題です。 具体的には、以下の図のようになります。ナ

    動的計画法(ナップサック問題) - アルゴリズム講習会
  • Protocol Extensionsのwhere句を使ってTraitを実現し、BaseViewControllerを排除する

    iOSアプリの開発において共通処理をBaseViewController(仮)のような親クラスに定義して、 各画面はこの親クラスを継承するといった実装がわりとあるかなと思います。 このような実装の場合、BaseViewControllerが肥大化して、見通しの悪い設計になりがちです。 また、独自フレームワークのような実装になってしまう傾向があり、 チーム開発においては、メンバーの学習コストが上がるなどのデメリットがあります。 その一方、各viewControllerに共通で入れたい処理というのはあるので、 そういった場合は、Protocol ExtensionsのWhere句を利用してTraitを実現するといいなと考えています。 例えば、UIActivityViewControllerを使って、データを共有する処理を共通化する場合 BaseViewControllerを利用した実装は下記の

  • codic - デベロッパーのためのネーミング辞書

    codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。

    codic - デベロッパーのためのネーミング辞書
    stilo
    stilo 2017/01/11
    仕事で キラキラネーム好きな人がいて、しょっちゅうリネームを求められてて、ネーミングに疲れてきたので、これ使いはじめた。
  • 全ての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は、あらゆる学生がコンピュータサイエンスを学ぶ機会を提供するという共通の目的を掲げているそうです。

    全てのApple Storeで、12月5日-11日に「Hour of Code」の無料ワークショップを開催 | Apple Store | Mac OTAKARA
    stilo
    stilo 2016/11/18
    申込Done!娘と行く。
  • DRYと不当な抽象化によるコストについて | POSTD

    記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、

    DRYと不当な抽象化によるコストについて | POSTD
    stilo
    stilo 2016/11/02
    なんかこれすごくわかる。DRYは正論だから 悪いわけじゃないんだけど。。。
  • Fitbitから取得した心拍データで時系列の異常検知を試してみる - About connecting the dots.

    井出先生の「異常検知と変化検知」を読んで,自分でも試してみたいと思ったんですが,あいにくちょうどいい時系列データが手元にないなーと思ってました.そんな折,データサイエンスLT祭りの発表の中に,Fitbitデータを可視化するものがあって*1,これはちょうどいいということで試してみましたよというていのエントリになります. 異常検知と変化検知 (機械学習プロフェッショナルシリーズ) 作者: 井手剛,杉山将出版社/メーカー: 講談社発売日: 2015/08/08メディア: 単行(ソフトカバー)この商品を含むブログ (2件) を見る Fitbitってなによ Fitbitが何かしらない人のために一応説明しておくと,最近はやりの活動量計です.私が持っているのは,心拍が取得できるタイプのやつです.風呂に入るとき以外は一日中つけっぱなしで,睡眠とか運動とかを自動で判定してくれるので,手間がかからず便利です

    Fitbitから取得した心拍データで時系列の異常検知を試してみる - About connecting the dots.
  • O'Reilly Media - Technology and Business Training

    O'Reilly Media - Technology and Business Training
    stilo
    stilo 2016/10/11
    とりま「Swift Pocket Reference」をダウンロードした。
  • 全く新しい銀行を1から作るために必要な技術 (Monzo公式ブログより) - Qiita

    あらまし 今年(2016年)8月10日、イギリスで全く新しい銀行が誕生しました。 イギリスの金融当局、PRA が、「Monzo Bank Ltd」を制限付きで認可。2015年2月に設立以来、別のカード会社と提携してプリペイドカードを発行し、その利用状況をスマホ等で即時に確認できるサービスを限られた顧客に提供してきましたが、これから当局との調整を進め、2017年前半を目処に銀行としての業務を開始すべく準備を進めるとのことです。 技術要素 過去にUberの競合であるHailoや、イギリスのオンラインカラオケサービス等でエンジニアを務め、現在 Monzo の Head of Engineering である Oliver Beattie氏が、公式ブログで「Building a Modern Bank Backend」と題し、技術要素についての説明をしているので、その内容を簡単に紹介します。 マイク

    全く新しい銀行を1から作るために必要な技術 (Monzo公式ブログより) - Qiita
    stilo
    stilo 2016/10/04
    マイクロサービス事例。秘伝のタレより美味しいかも。
  • すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない

    「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう(そういう人は結構たくさんいる)。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手にして抽象化を行うのは、ほとん