GitHub - codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
アプリの個人開発の終焉と新たな可能性 - ボクココ
ども、@kimihom です。 今回は私が今まで開発して来た個人開発と、そこで学んだ次の可能性について記していく。 個人で開発したアプリで食っていく 今でもちょくちょく個人開発をしている方をよく見かける。安定した仕事に勤めていた頃、私もその個人開発者のうちの一人だった。週末や空き時間があれば、ひたすらスマホアプリを開発し、私が作ったアプリの合計は十数個にのぼる。最初はゴミみたいなアプリを量産してたわけだけど、経験を積むにつれていいアプリを作る感覚を持てるようになって、１つだけ当たったアプリ(個人開発で15万DL 超えのアプリ)を作ることができた。この"当たるアプリを作る感覚"ってのは、アプリのアイディアそのものであったり、開発だけでないデザインやストアに掲載する文言やSEO、シェアされる仕組み、その他運用テクニックなど多様なものだ。 個人開発を可能にした背景に、スマートフォンアプリの流行が
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
O'Reilly Japan - ベタープログラマ――優れたプログラマになるための38の考え方とテクニック
プログラマとしてのキャリアをスタートすると、構文や設計を理解するだけでなく、その他の様々な事柄を理解し習得する必要があると気づきます。本書は、優れたコードを作りだし、人々と効率的に働く生産性の高いプログラマになるための考え方とテクニックを38のテーマで紹介します。はじめに、コード1行1行の書き方、デバッグやエラー処理、コードの改善方法など開発現場でのコーディングを取り上げます。次にコードを単純に保つこと、コード変更やテスト、リリースなどソフトウェアを開発する際の考え方や心構えを扱います。個人的な活動として、継続的な学習方法と停滞を避けるための課題の見つけ方など、自らを成長させる方法も紹介。さらに組織の中で他の人とコミュニケーションを取りながら、効果的に働くための習慣を解説します。『Code Craft』の著者Pete Goodliffeが、自らの経験を元に「優れたプログラマ」になるための考
15週間でクソゲーを20本作って得たもの - Qiita
5の「振り返り」は以下の項目を検討しておくと良いです。 Idea：アイデア。コンセプト。テーマ。元ネタ What went right：やってみて良かったこと。うまくいったところ。成功したところ。次回に生かせそうなこと What went wrong：ダメだったところ。うまく機能しなかったところ。問題点。改善すべき点 What I learned：学んだこと。効果的なゲームデザインの方法やツールの使い方、獲得したテクニックなど ちなみに最初にリンクを貼った、作ったゲームの各ページの下の方には、振り返りや作成にかかった時間などを記載しています（以下はノンフィールドRPG「OneWay RPG」を作った時の振り返り) Game A Weekで得たもの ということで「Game A Week」を行った結果、私が得たものです。 ゲームを作りながら技術検証できる ゲームを完成させたときの達成感を繰り返
Rails：Service層を運用して良かったところ、悪かったところ - Qiita
1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください！ Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ
例外設計、チェック例外の是非 - torutkのブログ
最近、Javaの例外について、特にチェック例外について否定論を見かけることがありました。Kent Beck、Robert C. Martin、Bluce EckelといったJava・オブジェクト指向プログラミングにおいて見識ある著名な人物がこぞって否定論を唱えています。自分的にはいまだ同意できないのですが、これだけの人物が並んで唱えると、ちょっと弱くなってチェック例外って本当に使うのが最善なのか考えてしまいます。 チェック例外について、賛成の立場で議論がないか探してみたところ、よい記事がありました。 http://littletutorials.com/2008/04/27/exceptional-java-thoughts-on-java-exceptions/ から始まる一連の記事で、チェック例外について賛成の立場で例外設計を述べています。また、戻り値と例外についても議論があり、例外設
続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
齢30を越えてようやく気づいたWebエンジニアの勉強に関するベストプラクティス - おうさまのみみはロバのみみ
…を書こうと思っていた矢先に↓が投稿された。 しかもぼくが書こうとした内容よりも理論付けられていたり、充実した内容だったり、深掘りされてたりして非常に良いのでこれ読めばだいたい終わるし書かなくていいじゃんね！ってなった。 完。 employment.en-japan.com これを読んだあとで「あーこんな良いエントリあるならぼく書かなくてもいんじゃね？っていうかぼくも知らない内容書かれてて充実度で完敗だし書く必要性無くね？？」とか思って書かないでおこうかと思っていたのだけども 別にぼくが似たようなことを書いてもPV数やまとまっている内容の充実差で件のエントリに微々たる影響を及ぼすこともなかろう、あと単純に書いて頭の中を整理しておこうと思い直したので今書いてる。 タイトルは元々の主旨なのだけどそれは↑を読めば満足できると思うのでこのエントリはそこからちょっと外れているものを書いておこうと思う
アプリケーションから例外を投げる派、投げない派 - Shin x Blog
例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ
プログラミングでよく使う英単語のまとめ【随時更新】
対になる言葉 comment out / uncomment コメントにする、コメントを解除する。 comment out は into a comment の意味。 comment だけならコメントする、評するの意味になる。 add / remove 追加する、削除する。 リストなどに値を入れる場合などにも使われる。 特に、末尾に追加する場合は append、先頭に追加する場合は prepend を使う。 Add A to B で、A を B に加える。 Remove A from B で、B から A を取り除く。 start / stop 開始する、止める。名詞だと開始、停止。 静止状態から動き出す感じが start。 途中からでも使える。 バーコードや通信の符号で StartCode / StopCode という使い方をする。 begin / end 始める、終わる。 最初の一歩を
Writing An Interpreter In Go
In this book we will create a programming language together. We'll start with 0 lines of code and end up with a fully working interpreter for the Monkey* programming language. Step by step. From tokens to output. All code shown and included. Fully tested. Buy eBook for $29 Buy paperback for $39 eBook includes PDF, ePub, Mobi (Kindle) and HTML. Read a free sample. Current version: 1.7. Released 7.
Go 言語で wc を実装してみた - takatoshiono's blog
Go 言語で wc を実装してみた GitHub - takatoshiono/go-wc: Go implementation of wc command for practice なぜか A Tour of Go をやり終えた時「全然うまく書けない」というのが感想だった。もっと Go 言語のコードを読み書きする必要がある。 そして読むだけだとやる気が続かないから何か書きたい。何を作ろうか？ Go 言語なのでスタンドアローンで起動するバイナリ実行形式のファイルがよさそう。仕様が簡単で手頃なやつがいいな...と考えて wc にしたのだった。他にも以下が候補にあった。 ab smtp server beer コマンド(なんかうまそうなビールを表示する) wc コマンド find コマンド (コマンド系で攻めるなら GNU coreutils, findutils などを見るとよさそうか...
Scala使用歴5年のプログラマが、この言語とその環境に関する神話を解き明かす | POSTD
(注：2016/1/21、頂いたフィードバックをもとに記事を修正いたしました。) 『 Programming in Scala (Scalaでプログラミング) 』の初版を読み始めた（でも読み終えていない）5年前からJavaの代わりにScalaを使うようになりました。最初はテストの時に使用していましたが、すぐにちょっとしたユーティリティクラスでも使用するようになり、気付いたらプロジェクト全てで使用するようになっていました。 Scalaに対する不満は多く存在しますが、この記事は違います。これは非難するものではなく、むしろ称賛するものです。 Scalaに興味ある開発者や聞いたことがあっても詳しく見たことがない人、「スムーズなプログラミングの妨げになる」と思い使用を先送りしていた人のために書きました。もちろんScalaファンに読んでもらうのも、他の人にも紹介してもらうのも大歓迎です。 この記事は3
ソースコードって実際のところどういうふうに書いていますか？｜Rui Ueyama
私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting...
「ZOZOTOWN作り直しにつき「40名」のエンジニア求む！」について、尾野（しっぽ）tail_y さんのツイート
マイクロサービスのアンチパターン
Write Code Every Day
今日の習慣が明日をつくる～よりよい技術者を目指して～
