サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
applis.io
Ruby言語の本を選ぶ基準前述の通り、Ruby言語の本はたくさんあります。この中で、どういう基準で本を選べばいいのでしょうか?これは、次の3つを確認するといいです。 Rubyのバージョンが古すぎないこと自分のレベルに合った本であること読みやすいことそれぞれについて説明します。 1. Rubyのバージョンが古すぎないことRuby言語は日々バージョンアップしています。中には古いバージョンと互換性がないものもあります。つまり、使用するRubyのバージョンによっては、本の内容が正しく動作しないことがあります。基本的には、このことが問題になることはありません。これは、本の中で「このバージョンを使ってください」という説明があるからです。 ただ、本で使用しているRubyのバージョンが古すぎると、せっかく学んだ内容の一部が役に立たないこともあります。これを踏まえて、あらかじめ本で使用されているRubyのバ
文章を書く前にやることよい文章を書くには、実際に文章を書く前に、読者は誰か、どういう悩みを解決するのかを企画することが大切です。また、それを元にアウトラインを書いておきます。 このふたつを元に文章を書くことで、読みやすい開発ドキュメントにつながります。これについては、次の記事をご覧ください。 開発ドキュメントを書く前に決めるべき3つのこと【企画編】開発ドキュメントにおけるアウトラインの書き方開発ドキュメントの書き方企画とアウトラインの作成が終わったら、実際に文章を書いていきます。文章を書くときは、次の9つを意識して書きます。これだけで、読みやすさ、分かりやすさが大きく向上します。 一文を短く切る結論を先に述べる指示語を使わない主語を明確にする、述語との距離を近づけるひらく・閉じるを統一する再現条件を示す前提を揃える見出しや箇条書き、表などを適切に用いる読者に伝わる用語を使うひとつずつ説明し
校正とは何かまず校正について整理します。校正とは、文章の誤りを正す作業になります。例えば誤字・脱字を見つけて、それを直す作業が校正です。 この校正は、元々は「原稿と製作物の文字に違いがないかを、一字ずつ確認する作業」のことを意味していました。他にも校正には、次のような「読みやすい文章にするための修正」も含まれます。 一文が長すぎないから抜き言葉はないか敬体・常体を混ぜていないかこのように、よりよい文章にするために必要なプロセスが校正になります。開発ドキュメントを書くときはもちろん、ブログだったり、Twitterだったりなど、文章を書くときにこの校正という作業をすることによって、よりよい文章につながっていきます。 自動校正ツールこの校正という作業は、目視で行うことができます。私もよく目視で校正を行います。ただ目視だけだと、どうしてもミスが発生してしまいます。人がやる以上、このミスは避けられな
ブログをはじめよう技術ブログの始め方を、たくさんの画像で分かりやすく解説しました。これまでブログをやったことがない人でも、エンジニアにとって重要なブログを今日から始められます。
PlantUMLとは次に、PlantUMLについて簡単に説明します。PlantUMLは、テキストベースでシーケンス図を書くことのできる、UMLの一種です。シーケンス図を書く方法はいくつかありますが、この記事ではPlantUMLでシーケンス図を書く方法を解説していきます。 前提条件この記事では、すでにPlantUMLが動作する環境がある前提で解説していきます。もしまだ環境を構築していない場合は、インターネットで「PlantUML 環境構築」などで検索して準備してください。 あるいは、次のようなオンライン上でPlantUMLを実行できるサービスもあります。こちらを利用しても問題ありません。 PlantUML EditorPlantTextPlantUML Web Server メッセージメッセージの例メッセージは、システムの構成要素(分類子)同士のやりとりを表現します。シーケンス図は、このメッ
PKCEとは何かPKCEは「アクセストークンを安全にやり取りするための、OAuth 2.0の拡張仕様」です。Proof Key for Code Exchangeの略で、意訳すると「安全にコードをやりとりするための証明鍵」となります。 PKCEは2015年9月にRFC7636として定義されています。「ピクシー」と発音します。 一般的な認可フローOAuthを用いた一般的な認可のフローを見てみます。ユーザーがアプリにアクセスすると、認可を求められます。ユーザーは認可サーバー上で認証を行い、成功すると認可サーバーからアプリ側にコードが渡ります。 一般的な認可のフローアプリは受け取ったコードを元に、認可サーバーからアクセストークンを取得します。あとはアクセストークンを元にプロフィール情報などを取得して、ユーザーに画面を表示します。これが一般的な認可のフローになります。 第三者によるアクセストークン
プログラミングを始めたいけど、何から始めていいかわからない。あるいはプログラミングを学び始めたけど、テキストエディタの使い方がよくわからない。このような悩みを持っていないでしょうか?プログラミングをする上で大切な要素にテキストエディタがありますが、エディタの使い方を学ぶ機会はなかなかありません。 この入門では、Visual Studio Code(VSCode)の基本的な使い方を徹底的に学んでいきます。VSCodeのインストール・日本語化から入るので、まだプログラミングの知識がなくても問題ありません。マルチカーソル・コマンドパレットなど、現場のエンジニアが使いこなしている実践的な機能も学んでいきます。 この入門を学ぶことで、エンジニアとして一生使っていく大切な仕事道具であるテキストエディタの基本的な知識が身に付きます。エンジニアとしての学習・仕事の基盤ができ、長期的な収入・セルフブランディ
私は2013年からはてなブログやZenn、Qiitaなどのブログサービス上で技術ブログを書いてきました。ブログをどこで書くべきか?ということをふだんから考えていて、その内容は情報発信タグをつけて記事として公開したりしています。 技術ブログをはじめようと思ったとき、世の中にはたくさんのブログサービスがあるので、どれがいいのか悩むかもしれません。理想的にはWordPressがいいのですが、運用するためのお金がかかってしまいます。 お金をかけずに技術ブログを始める方法として、私は次の2つのサービスををおすすめしています。 はてなブログZennこの記事では、そもそもどういうブログサービスがあるのか?という選択肢と、選ぶときの基準、また上記2つのサービスがおすすめな理由を解説します。この記事を読むことで、納得した上で技術ブログを始めることができると思います。
私は2013年に技術ブログを開設し、継続的に記事を書いています。ただ、初めの頃は書くことが見つからず、書きたいのに書けないといったことがありました。 このような悩みについて、この記事では技術ブログのネタを出す方法、ネタを作るためにやるべき習慣について解説します。この記事を読むことで、記事を書こうと思ったときにすぐ書き始められるようになると思います。
エンジニアとして情報発信をすべきなのは、なんとなく感じているかもしれません。ただ本当に必要なのか、あるいは情報発信をするとして、何をすればいいのか分からないかもしれません。 私はTwitterやGitHub、また本ブログをとおして情報発信をしてきました。転職の面談で評価の対象となったり、情報発信をとおして仕事の依頼を受けたこともあります。また、過去に情報発信をやめてしまった期間もあります。 この記事を読むことで、エンジニアの方が情報発信をすべき理由と、なにをすればいいのかがわかります。情報発信に悩んでいたら、ぜひ読んでみてください。
システムの権限管理を設計することになったとき、どのようにすればいいか分からないかもしれません。この記事では、権限管理とは何か、その際に押さえておくべきRBACとABACについて、また権限管理を設計するときの考え方を解説しています。 私はエンジニアとして、主に立ち上げのフェーズでサービスを開発してきました。権限管理は、どのサービスにも必ず入ってくるプロセスでした。ここでの経験や、調べたことを元にこの記事を書いています。
ユーザー認証を実装することになったとき、どう設計すればいいのかが分からないかもしれません。あるいは、認証にはいろんなやり方がありますが、採用しようとしている方法で問題ないかが不安かもしれません。 この記事では、ウェブアプリケーションやネイティブアプリでのユーザー認証の仕組みや方法を説明した上で、どの方法がいいのかをケースごとに見ていきます。 私はBtoB、BtoCのウェブアプリケーションやモバイルアプリをいくつか作ってきました。その度に、ソフトウェアの種類に応じたユーザー認証について考え、設計・実装してきました。その経験をもとにこの記事を書いています。
運用しているシステムに障害が起きてしまったとき、どうすればいいのか分からないかもしれません。また、障害が起きたときのために、どのように対応をするかを学んでおきたいこともあると思います。 この記事を読むことで、障害が起きたときの業務フローを学ぶことができます。また、実際に障害が起きたときに見ながら対応することで、復旧につなげることもできます。さらに、障害が起こらないための準備についてもまとめています。 私はエンジニアとしてシステムを開発や運用してきました。この中で経験した障害対応で得た知見をもとに解説します。 この記事では、ウェブサービスやモバイルアプリの障害対応を想定して書いています。他の領域における障害対応でも参考になるかもしれませんが、当てはまらないこともあることをご承知おきください。また、想定している読者の方としては、エンジニアとしての実務経験が1〜3年目の方としています。
管理画面を開発することになったとき、どう作ればいいのか分からないかもしれません。管理画面のデザインに関する記事はたくさんありますが、設計については情報が少ないという問題があります。 私はこれまでいくつかのプロダクト開発に携わってきました。そのほとんどが管理画面をもっていました。この経験を元に、管理画面を設計する上でなにを考えればいいかを解説します。また、プロダクトのフェーズにおける管理画面の考え方についても整理します。 この記事を読むことで、管理画面の作り方がよくわからない状態から、どう作りはじめればいいかがわかるようになると思います。
この記事では、ブログを始めるときの全体像と、その具体的な手順について解説します。初めてブログを作る人にも分かりやすいように、画像をたくさん用いて説明しています。 私はプログラミングを学び始めたころ、ブログをどうやって作ればいいのかがよく分かりませんでした。今となっては仕事やプライベートでたくさんのブログを作ってきたので、この経験を元に記事を書いています。 ブログを作るのには時間がかかりそう……と思うかもしれませんが、この記事を読むことで、自分だけのブログが15分くらいで完成します。つまり、プログラミングの学習やエンジニアとしての成長に重要な技術ブログを、今日から始めることができます。
ソフトウェアを開発する上でしっかりと設計しておきたいのがログの出力です。私は以前、運用しているウェブアプリケーションのログ出力のフォーマットが不十分だったため、問題が起きたときに原因の調査ができなかったという苦い経験があります。そのときから、ログの出力の設計について気をつけるようにしています。 この記事ではログの出力を設計する方法について、フォーマットやメッセージの書き方を例をもとに解説します。ログを設計するときの参考になればうれしいです。
私は本ブログを書いたり、また技術書を出版するなどして文章の書き方について学んできました。今では自分なりの型ができましたが、初めの頃はうまくかけませんでした。 この記事では、「技術ブログを書きたいけど、うまく書けない」や「読んでもらえる書き方を知りたい」といった悩みについて、次の4つのステップで記事の書き方を解説します。 記事を設計するタイトルを作る導入文を書く本文を書くこの記事を読むことで技術ブログの書き方がわかるようになります。あなたのブログがたくさんの人に読まれるようになって、ブログを書くのがもっとたのしくなると思います。
ソフトウェアを開発するときは、テストケースが重要になってきます。この記事をお読みの方はまさに今、テストケースの設計にお悩みかもしれません。私はこれまでウェブエンジニアとしてソフトウェアの開発に携わってきました。この経験をもとに、テストケースとは何か、作り方や書き方、項目の洗い出しについて解説します。 この記事は、ソフトウェアのテストケースを設計する方、特にテストケースの設計経験が少ない方を対象としています。また、私はウェブエンジニアなので、その文脈でまとめています。テストケースを設計するときの参考になればうれしいです。
システム開発における技術選定とはこの記事でいう技術選定とは、その名のとおり「どんな技術を使うかを選ぶこと」です。領域はインフラやサーバーサイド、フロントエンド、また種類としては言語やフレームワーク、ミドルウェアなどが対象になります。 この記事ではライブラリの選定基準については書いていません。これについては「ライブラリの選定基準」で詳しく書いていますので、あわせてご覧ください。 なぜ技術選定をするのか技術選定の目的は「事業価値を最大化するため」だと考えています。技術選定というと、ついシステム要件を満たすために決めてしまいがちです。もちろんこれも必要ですが、選定の観点という意味では一部でしかありません。 企業において、開発は事業を運営するために行います。OSSの場合は「事業」を「ソフトウェア」に置き換えられると思いますが、使う技術は事業に大きく影響します。たとえば、技術を使える人の採用コストだ
チームでソフトウェアを開発するとき、ソースコードレビューをすることがあると思います。私もレビューをよくするのですが、やる度にレビューの観点が変わってしまっているような気がしていて、一度整理しようと思いました。 この記事では、ソースコードレビューとはなにか、目的ややり方、観点のチェックリストについて書いています。レビューをするときの参考になればと思います。
私はふだんの開発でGitHub上でプルリクエストを出すとき、なんとなくフォーマット化したものを使っていました。プルリクエストについて整理するために、この記事でプルリクエストとはなんなのか、誰が読むのか、目的はなにか、書くべきことなどをまとめてみました。 記事の後半にはプルリクエストのテンプレートもありますので、よりよいプルリクエストにするための参考になればうれしいです。
ライブラリの選定基準ひとつひとつ見ていきます。 1. メンテナンスされているかコミットログの頻度や、Issues/Pull Requestsの対応状況を見てみます。コミットの頻度が少なかったりバグが放置されていたりすると、モンキーパッチなどで対応することになるかもしれません。 GitHubなら、開発者の方の草の生え具合を見てみるのもいいかもしれません。 2. 破壊的な変更は多くないかCHANGELOGを見てみます。破壊的な変更が多いと、追随するためのコストが高くなるリスクがあります。 3. 使われているかライブラリが使われているかどうかで、開発者の方のそのライブラリに対するモチベーションを推測することができます。GitHubならスター数などが参考になると思います。 4. リリースされてから十分な時間が経過しているかリリースして間もないライブラリだと、将来の変更が見えづらいという問題がありま
このガイドは、まだアイデアがない状態からスタートし、プロダクトが市場に受け入れられることをゴールとしています。このために、次の4つの問いに対する答えを、ひとつずつ検証しながら決めていきます。 誰の課題を解決するのかどんな課題を解決するのかどう解決するのかどう提供するのかなぜこの手順で進めるのでしょうか?たとえば、ありがちな例として「こういうプロダクトをつくりたい」という話があります。このアイデアの切り口は、3の「どう解決するのか」から入ってしまっています。 つまり、このプロダクトはどんな課題を解決するのか、そもそもその課題を抱えている顧客が本当に存在しているのかがわかりません。失敗しないプロダクトをつくるためには、顧客や課題、解決策をひとつひとつ検証しながら前に進む必要があるのです。 この章でやることこの章ではFounder Customer Fitをめざします。解決したい課題はなにか、顧
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
この記事はRails Advent Calendar 2020の24日目の記事です。今月中旬に見てみたら24日だけ空いていたので参加を申し込みました。よろしくお願いいたします。 Ruby on Railsアプリケーションのディレクトリ構成としては、大きくmodelsとcontrollers、viewsがあります。ここにコードを書いていくことになります。実装が進むにしたがって問題になりやすいのが、Fat ModelやFat Controllerといったコードの肥大化に関する問題です。これは適切にデザインパターンを導入することで防ぐことができます。 この記事では、Railsにおけるデザインパターンとはなにか、その必要性やデザインパターンの一覧について書いていきます。なお、Railsアプリケーションの開発についてより詳しく学びたいときに参考になる本を次の記事でまとめています。あわせてご覧ください
なぜProduct Market Fit SurveyをするのかProduct Market Fit Surveyは、PMFの達成を判断する材料にするために行います。プロダクトをつくりはじめるとき、最初にめざす大きな目標がPMFです。PMFを達成することで、プロダクトに対する投資効率を最大化できます。 逆にいうと、PMFにいたっていない段階での投資は、穴の空いたバケツに水を注ぐようなものです。プロダクトはPMFを達成する必要があり、PMF Surveyはこの達成を判断するために重要な指標である、ということになります。 なぜProduct Market Fit Surveyなのかそもそも、なぜProduct Market Fit Surveyがよいのでしょうか。PMFを判断するためのテストは、PMF Survey以外にもNPS (Net Promoter Score)などがあります。 PMF
Ruby on RailsアプリケーションのコードをリファクタリングするためのデザインパターンのひとつにValueオブジェクトというものがあります。このパターンをうまく導入することで、モデルが肥大化するFat Modelという問題を防ぐことができます。 この記事ではValueオブジェクトとはなにか、導入する必要性や導入方法について書いていきます。
ウェブサービスやアプリなどのアイデアを思いついたとき、そのアイデアの中にはたくさんの仮説が隠れています。「こういう人は、こんなときにこの行動をするはずだ」というような仮説です。この仮説を仮説のままにしておくと、思うように使われないプロダクトになってしまうかもしれません。 仮説は、それが本当に成り立つかどうかを、プロダクトがアイデアの状態から運用段階にいたるまで、検証し続ける必要があります。ただ、どの仮説を検証すればいいのか?ということが分からないかもしれません。 私はプロダクトマネージャとして、ウェブサービスやアプリを開発してきました。この経験をもとに、検証すべき仮説を見つける方法として、「仮説マトリクス」という図の作り方について解説します。
この記事の目的対象となる読者はエンジニアの方で、とくに「技術記事をどう書けばいいかわからない、伝わるか不安」という方を想定しています。技術ブログの記事やドキュメントといった技術記事を書くときの指針となるポイントについて示します。 この記事をとおして、よりわかりやすい記事を書けるようになることを目的とします。 技術記事とは技術記事とは技術ブログの記事やドキュメントなど、書き手の経験をもとにした体系的な知見や、課題とそれに対する解決策を示したものなどをいいます。書き手自身の知識の定着やメモになるのはもちろん、読んだ人に技術的な知見を提供する役割をもちます。 また「自分がその知識をもっている」ということを周知することでブランディングにもなります。 背景前章のとおり技術記事は書き手にも読み手にもメリットのある重要な文書です。記事の存在だけで十分に価値があるといえます。 一方で「用語が難しい」「再現
次のページ
このページを最初にブックマークしてみませんか?
『applis - プログラミング初学者のための技術ブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く