サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Appleイベント
applis.io
Ruby言語を本で学びたいと思ったときに、どの本がいいのか分からないことはないでしょうか?私も初めてRubyを学ぼうと思ったとき、どの本がいいのか悩んだ記憶があります。この記事では、Rubyの本を選ぶ基準を示した上で、おすすめの本として厳選した次の3冊を紹介します。 ゼロからわかる Ruby超入門プロを目指す人のためのRuby入門Effective Ruby私はRuby on Railsアプリケーションの開発に携わっています。また、Rails関連の本を書いたこともあります。こういった経験を元に解説していきます。Rubyの学習に役立つ本が見つかると嬉しいです。 Ruby言語の本を選ぶ基準前述の通り、Ruby言語の本はたくさんあります。この中で、どういう基準で本を選べばいいのでしょうか?これは、次の3つを確認するといいです。 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つのサービスがおすすめな理由を解説します。この記事を読むことで、納得した上で技術ブログを始めることができると思います。
上の組み合わせでネタを洗い出すと、例えばフロントエンドエンジニアの方が仕事でNext.jsやTailwind CSSを使っているとき、「Next.jsやTailwind CSSといったライブラリについての紹介記事を書こう」という考えが生まれます。 この対象と領域、テーマをあらかじめリスト化しておきます。書くことがないときに組み合わせることで、たくさんのネタを見つけることができます。次に、この3つの要素についてひとつずつ見ていきます。 ① 対象対象とはあなたが技術情報をインプットした場所のことです。例えば次のようなものがあります。ふだんインプットしている場所をリスト化しておきましょう。 仕事で開発中のシステム個人開発中のシステム読んだ本OSS活動参加した勉強会② 領域領域はどの技術領域についての記事を書くかです。例えば次のようなものがあります。①の対象における技術的な領域をリスト化してみてく
エンジニアにとっての情報発信とはエンジニアがする情報発信とは、主に技術情報の共有を目的として発信することです。たとえば、次のような技術情報を文章として公開したりします。 バグとその解決方法ライブラリの紹介新しい技術に対する考察あるいは、作ったライブラリを公開することも情報発信のひとつです。 エンジニアが情報発信をすべき理由エンジニアの方が情報発信をするメリットとして、大きく次の4つがあります。 セルフブランディングになる他の誰かの役に立つ自分のためになる文章力が向上するひとつずつ見ていきます。 1. セルフブランディングになる情報発信をしていると、内容によっては転職や社内での面談のときに評価されたりします。また、あなたのスキルがわかるようになるので、あなたのスキルを頼りに仕事の依頼が来たりします。 あなたの人となりもわかりますので、他のエンジニアの方とコミュニケーションが取りやすくなったり
システムの権限管理を設計することになったとき、どのようにすればいいか分からないかもしれません。この記事では、権限管理とは何か、その際に押さえておくべきRBACとABACについて、また権限管理を設計するときの考え方を解説しています。 私はエンジニアとして、主に立ち上げのフェーズでサービスを開発してきました。権限管理は、どのサービスにも必ず入ってくるプロセスでした。ここでの経験や、調べたことを元にこの記事を書いています。
ユーザー認証を実装することになったとき、どう設計すればいいのかが分からないかもしれません。あるいは、認証にはいろんなやり方がありますが、採用しようとしている方法で問題ないかが不安かもしれません。 この記事では、ウェブアプリケーションやネイティブアプリでのユーザー認証の仕組みや方法を説明した上で、どの方法がいいのかをケースごとに見ていきます。 私はBtoB、BtoCのウェブアプリケーションやモバイルアプリをいくつか作ってきました。その度に、ソフトウェアの種類に応じたユーザー認証について考え、設計・実装してきました。その経験をもとにこの記事を書いています。
私もかつてはそうでしたが、運用の経験がない方にとっては、障害対応というと「復旧」だけだと思いがちだと思います。ただ、復旧は障害対応の一部に過ぎません。上の7つのプロセスをしっかりと押さえておきたいところです。 1. 関係者への周知それでは障害対応についてひとつずつ見ていきます。まずは関係者への周知についてです。このプロセスでは、システムに関わるメンバーに障害について周知します。とくに、2の「体制構築」に関わるメンバーには確実に共有できるようにします。 周知の方法については、社内で使っているチャットツールなど、全体に通知できる方法を用います。書く内容としては、次のような項目が考えられます。 障害の内容いつ発生したか原因はなにか影響範囲障害対応にあたるメンバーおよびリーダー対応内容完了目処周知の段階で、わからないことは一旦未定でいいと思います。障害対応に進捗があったとき、必要に応じて随時周知を
1. 認証をどうするか決めるまず認証をどうするか決めます。GoogleやSlackなどのアカウント連携がよさそうです。どのアカウントを使うかは、組織が利用しているプラットフォームに応じて決めればいいです。あとは、IPアドレスによる制限をかけるなど、他の手段とあわせて認証するとセキュリティが強化されます。 実装がラクだからといって、プロダクト本体のユーザー基盤を利用してしまうと、セキュリティの担保が難しくなったり、管理画面がプロダクト本体と密結合になってしまうので、基本的には避けた方がいいと思っています。 2. 認可する対象を決める次に認証した運用者の役割によって許可する操作を分けていきます。たとえばアルバイトや業務委託の方など、アクセスしていいデータが変わってくることがあるので、これを分けます。 やり方としては、まず管理画面上の操作の一覧をスプレッドシートなどに書き出し、許可する役割をセッ
この記事では、ブログを始めるときの全体像と、その具体的な手順について解説します。初めてブログを作る人にも分かりやすいように、画像をたくさん用いて説明しています。 私はプログラミングを学び始めたころ、ブログをどうやって作ればいいのかがよく分かりませんでした。今となっては仕事やプライベートでたくさんのブログを作ってきたので、この経験を元に記事を書いています。 ブログを作るのには時間がかかりそう……と思うかもしれませんが、この記事を読むことで、自分だけのブログが15分くらいで完成します。つまり、プログラミングの学習やエンジニアとしての成長に重要な技術ブログを、今日から始めることができます。
ログ出力の設計指針とはまず、ログとは「アプリケーションやサーバ、ソフトウェアなどが出力する、時系列に記録されたデータ」のことをいいます。例えばアプリケーションが出力するログやデバッグログ、ウェブサーバのアクセスログやエラーログなどがあります。 これをふまえて、ログ出力の設計指針とは、アプリケーションなどのログの出力をどう設計するかという指針のことをいいます。 ログの種類によって、出力の設計指針は変わってくると思います。この記事では、いろんなログに共通する汎用的な内容として、アプリケーションログの出力を例に設計指針について書いていきます。 ログ出力の設計指針は、開発するソフトウェアによっても変わってきます。重要なことは、チームで指針をもってログ出力を行い、しっかりと運用していくことだと思います。 なぜログを出力するのかこれからログ出力の設計指針について書いていくのですが、そもそもなぜログを出
本記事の例表だけだとわかりづらいので、本記事を書いたときの上の各項目についてを次に示します。 ## キーワード * 技術ブログ, 書き方 ## ターゲット * 技術ブログを始めようとしている人 * ブログを書いているけど、いい文章が書けない人 ## 読者の悩み * 技術ブログを書きたいけど、うまく書けない。読んでもらえる書き方を知りたい。 ## 悩みが解決する条件 * 技術ブログの書き方がわかること ## 悩みの解決策 * 技術ブログの書き方について、次の4つのステップで解説する: 1. 記事を設計する 2. タイトルを作る 3. 導入文を書く 4. 本文を書く ## 記事を読むメリット * 技術ブログをたくさん読んでもらえるようになる * ブログを書くのがたのしくなる ## 記事の信頼性 * 本ブログを書いている * 技術書の出版を通して書き方について学んだ 1記事=1キーワード7つの項
以上をまとめると、ユニットテストなどのいろんな種類のテストについて、正常系と異常系をもとにテストの手順を書いていくのがテストケース、ということになります。 なぜテストケースを作るのかそもそも、なぜテストケースを作る必要があるのでしょうか?テストケースの設計に初めて携わる方は、その必要性が分かりづらいかもしれません。 テストケースは、「それをもとにテストを行う」という手順書になるのはもちろんそうなのですが、品質という意味でも次の3つの目的があります。 必要なテストを漏れなく実施するため不要なテストを削除するため誰が行っても同じテストにするためこの3つについて説明します。 1. 必要なテストを漏れなく実施するためソフトウェアが正しく動作するかどうかは、テストを通して確認します。言い換えると、テストケースが足りない場合、ソフトウェアが正しく動作しないかもしれません。例えばバグがあると、ソフトウェ
システム開発における技術選定とはこの記事でいう技術選定とは、その名のとおり「どんな技術を使うかを選ぶこと」です。領域はインフラやサーバーサイド、フロントエンド、また種類としては言語やフレームワーク、ミドルウェアなどが対象になります。 この記事ではライブラリの選定基準については書いていません。これについては「ライブラリの選定基準」で詳しく書いていますので、あわせてご覧ください。 なぜ技術選定をするのか技術選定の目的は「事業価値を最大化するため」だと考えています。技術選定というと、ついシステム要件を満たすために決めてしまいがちです。もちろんこれも必要ですが、選定の観点という意味では一部でしかありません。 企業において、開発は事業を運営するために行います。OSSの場合は「事業」を「ソフトウェア」に置き換えられると思いますが、使う技術は事業に大きく影響します。たとえば、技術を使える人の採用コストだ
他にもSHOULDを使う例をよく見かけますが、対応すべきかどうかが曖昧なのでMUSTかIMOに寄せるべきだと私は考えています。 2. コメントの仕方に気をつけるソースコードレビューのコメントはコミュニケーションでもあるので、コミュニケーションが円滑になるよう絵文字などを交えて投稿した方がいいと思います。 3. よいところもコメントする2と同じ理由ですが、ソースコードレビューはコミュニケーションであるので、相手をほめることも意識した方がいいと思います。また、よいところをコメントすることはメンバーの学びにもつながります。 4. 根拠を示すコメントが「こうすべき」だけだと、レビュイーは「なぜ?」と思ってしまいます。その根拠として、参考文献などをリンクで示すと親切です。 5. 進捗に応じて見るポイントを変える作業中のソースコードをWIPとして先にプルリクエストを出すやり方もあります。WIPのときは
私はふだんの開発で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このセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
Ruby on RailsにおけるデザインパターンとはRailsにおけるデザインパターンとは、モデルやコントローラ、ビューに頻出する実装パターンを、オブジェクト設計の原則にもとづいて抽象化したパターンのことです。デザインパターンにしたがうことで、設計上の問題を防ぐことができます。 例:FormオブジェクトたとえばFormオブジェクトというデザインパターンがあります。これはユーザーからの入力を整形・検証して永続化するという役割を持ちます。この処理はコントローラに書かれがちですが、このことはFat Controllerにつながりやすいです。 Formオブジェクトを導入することで、Fat Controllerの問題を防げます。またFormオブジェクト単体として再利用性が上がったり、テストが書きやすくなるといった利点もあります。 なぜデザインパターンが必要かデザインパターンは、アプリケーションが大
なぜ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ページを開く