Zenn｜エンジニアのための情報共有コミュニティつくりながら学ぶ！AIアプリ開発入門 - LangChain & Streamlit による ChatGPT API 徹底活用
Design It! - junebox
本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日本語版序文」を収録。
読みやすいコードを書くために - Qiita
この記事は、社内向けに書いた資料を公開の許可を得て加筆修正したものです。 記事中の具体例やサンプルコードはJavaScript/TypeScriptで書かれていますが、内容自体は言語にかかわらず使えます。 同僚の @shisama にも手伝っていただきました。 はじめに 命名について 条件式について 関数について 変数・定数について コメントについて 2020/11/02 ついに完結！ はじめに 読みやすいコードは、コメントがなくても文章を読むように理解できます。 逆に、読みにくいコードはコメントがあってもさっぱり意味がわかりません。 文章を読むように理解できるコードを書くために普段気をつけていることや、コードレビューの際に重点的に見ているところをまとめました。 普段から読みやすいコードを心がけている方にとっては何も目新しい物はなく、当たり前に意識しているであろうことばかりです。 特にプロ
開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
Rubyのまつもと氏、「気分を害することもある。だからどうか建設的であってほしい」
オープンソースソフトウェアの開発においては、コミュニティメンバーからのコードのコントリビュートだけでなく、さまざまな立場の人々から「この機能がほしい」「この動作はバグではないか」といった意見が寄せられます。 有名なオープンソースプロジェクトであるほど、そうした多くの意見やコメントを受け止めつつ開発は進んでいくわけですが、そうした状況は一方でさまざまな気苦労を生むであろうことは容易に想像が付きます。 人気のあるプログラミング言語として知られるPythonの生みの親であるGuido van Rossum氏は2018年7月、Pythonを開発する過程で生ずるさまざまな意思決定の気苦労から離れたいとの理由で、Pythonにおける「優しい終身の独裁者」からの引退を発表しました。 ちょうど新バージョン「Ruby 2.6」が登場したばかりのRubyに対しても、米国の掲示板redditで「[whining
エンジニアの名言メーゲン
コードをデバッグするのは書くことの２倍の労力が要る。つまりあなたの頭脳を最大限に使って書いたコードをデバッグするための頭脳はあなたには無い。
本当にあった怖いプログラム（クソコード事例集） | 株式会社アクシア
プログラマーはクソコードが大好きです。プログラマーが仕事を進める上でクソコードは本来全力で回避するべき対象であるにも関わらず、プログラマーはクソコードの話題が大好きです。みんな張り切って自分が経験してきたクソコードの話で盛り上がります。 昨日こんなツイートをしました。 プログラマーとして数年経験していれば誰でもクソコードの１つや２つ見たことあると思いますが、今まで「これはクソ」と思ったコードにはどんなものがありましたか？リプ欄で共有いただければ幸いです。 — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) April 26, 2018 そうしたら出るわ出るわ。皆さんのクソコード事例集があっという間に集合知として蓄積されていきました。エンジニアであれば誰しもクソコードの話題では盛り上がらざるを得ないわけですが、今回上記のツイートを私はある意図があって投稿しました。 そ
N予備校のプログラミングの入門コースがすばらしすぎる｜加藤貞顕
タイトルの通りなんですが、ドワンゴが運営する「N予備校」がやっている 【2017年度】プログラミング入門Webアプリ というコースがすばらしくてびびりました。前に書いた社員が自分ではじめていて、いいというのでぼくも試してみた。そしたら、あまりにもよかったので書いておく。 たとえば「第2章 準備しよう」の冒頭はこんな感じ。 いちばん上の「LinuxというOS」では、手元のPCに仮想環境をつくって、Linuxをインストールして、sshで使えるようにするセッティングを行う。 その後、基本的なLinuxの使い方から、TCP/IPのパケットを覗いてみたり、簡易チャットをつくったり、かんたんなbotをつくったり、Githubをつかったり、DBにさわったり、node.jsをつかったりする。ネットワーク時代のプログラミング入門として、非常によくできている。 いちおう、毎回2時間の動画をみながら学ぶ形式なん
プログラミングでよく使う英単語のまとめ【随時更新】
プログラミングでよく使う英単語のまとめ【随時更新】 随時追加、整理していきます。 名前をつけるときには、名詞、動詞の違い、複数形、過去形などに注意しましょう。 オブジェクト指向では、クラス名は名詞、メソッドは動詞とします。 使ってはいけない言葉 get / set アクセサ (getter / setter) やプロパティによく使われている。 それ以外に使うと混乱を招くのでよくない。 get は軽量な処理と考えるので、中に重い処理は書いてはいけない。 単純な取得/設定以外で使いたくなったら他の言葉を考える。 load, save, commit, store, enable, disable, fetch, register, configure, add, etc... check 意味が広すぎて何をしているかわからない。 できるだけ別の言葉を使う。 具体的に何をしているかに分解して考え
John Resig - Write Code Every Day
Last fall, work on my coding side projects came to a head: I wasn’t making adequate progress and I couldn’t find a way to get more done without sacrificing my ability to do effective work at Khan Academy. There were a few major problems with how I was working on my side projects. I was primarily working on them during the weekends and sometimes in the evenings during the week. This is a strategy t
「誰がこんなネーミングにしたんだ……。」プログラミングのネーミングルールを決める時に参考にしたい情報まとめ
サイトのメンテナンスにおいてしばしばネックになるのは、どんなネーミング・構成で制御しているのか分からなくなってしまうことです。しっかりと基準に則った、誰がいつ見てもわかりやすいネーミングでコーディングしていくことは、非常に重要なことです。 今回は、プログラマーがネーミングを考える際に参考にしたいサイトを選んでご紹介いたします。 1. codic - プログラマーのためのネーミング辞書 https://codic.jp/ 様々なサイトに紹介され、「ネーミング」で検索しても上位に表示される素晴らしいツールです。例えば、Webサイトの背景に動画を設置する際に、class名をどうしようか悩んだとします。そこでcodicに「背景動画」と入力すれば「background_videos」と提案してくれます。提案されたネーミング以外にも、その他の候補も出てきます。 考える労力を省くことができるという点で優
プログラミングの名言をもう少し | POSTD
前回投稿した「 The Wisdom of Programming （プログラミングに関する名言の知恵）」で、表面上は良さそうでも、ソフトウェアの開発において誤った考えを助長する結果になってしまう名言に注意を促しました。また、以前には「 favorite programming quotes 」（お気に入りのプログラミングの名言）というのも投稿していますが、もう少し名言を追加しておきたいと思います。 コーディング作業 「プログラムを詳細にわたって明確に記述する作業とプログラミングの作業は、全く同一のものである」―Kevlin Henney 「プログラム構築の本質のほとんどは、実際には仕様書のデバッグだ」―Fred Brooks 「よくある誤った考えは、プログラムの作成者は不可解なコードを書いてもコメント行で自分の考えを明確に表現できるだろうと思い込むことである」―Kevlin Henney
第1回 ラズベリーパイの組み立てと初めてのプログラミング（1）
子供の頃、筆者がよく見たアニメにはロボットものがたくさんありました。いつかロボットを作ってみたいと夢見た読者の方もたくさんいらっしゃるのではないかと思います。しかし実際は、ロボットの「頭脳となるソフト」と「身体となるハード」の両方を作って組み上げるなんて、ちょっと自分にはハードルが高すぎると、諦めてしまったのではないでしょうか？ そんな方に朗報です！ 「ラズベリーパイ」（Raspberry Pi）は手のひらに乗るほどコンパクトなサイズでありながら（図1）、れっきとしたコンピュータであり、しかも、外部のハードウエアと簡単に接続する仕組みが搭載されています。自分だけのオリジナルロボットを作るための必要な土台を提供してくれるのです。また、ロボット作りというテーマを通して、ソフトウエアとハードウエアの両方を同時に学べる優れた学習教材でもあります。 小学生でも“本当に”分かるように解説 この連載は、
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
スタック・オーバーフロー
python × 120 javascript × 50 c# × 34 python3 × 31 html × 31 c++ × 28 linux × 27 c × 26 java × 21 windows × 20 android × 16 ruby × 16 google-apps-script × 16 php × 15 css × 15 reactjs × 15 typescript × 15 docker × 13 aws × 12 pandas × 12 swift × 11 ruby-on-rails × 11 mysql × 11 unity3d × 11 node.js × 11 ubuntu × 11 vscode × 11 postgresql × 11 rust × 10 macos × 9 visual-studio × 9 laravel × 9 networ
改訂版: プログラマーが効果的な可視化を作成する （前編） - Qiita
改訂版について (5/7/2019公開) この記事は、私がこちらに公開したもの中では最も読まれているようです。そこで、執筆後に気づいたこと、古くなった情報、新しい技術動向などを考慮に入れて改訂をしました。主な変更点は以下の通りです： 新しいセクションの追加 最近の本の紹介 細かな表現の修正 この記事は複数のセクションに分かれていますので、前編から始め、順番にアップデートして行きたいと思います。何かお気付きの点などありましたら、コメント欄、もしくはkonoアットマークucsd.eduにお願いいたします。 はじめに この記事は、可視化の専門家ではない人がコンピュータを使ってデータ可視化を実際に行う場合に必要な、一般的なノウハウをお伝えするシリーズの第一回です。 前編: 効果的なデータ可視化とはどのようなものか？ （本稿） 中編: 分かりにくい可視化を避けるための手法の選択 後編: Part 1
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
リーダブルコードを読み終えて、ノンデザイナーズ・デザインブックを読み返す - アインシュタインの電話番号
今年のテーマは、積ん読を減らすことにした。良さそうな本があったりセールがあったりするとついつい買ってしまって、それである程度満足して読まないまま、というパターンにハマっていることが、AmazonのKindle日本上陸以降の自分の買い方で一目瞭然になってきたからである。ゆゆしき事態。 電子書籍は物理的なスペースを取るわけではないので、それが目に見えるわけではないんだけど、その電子書籍の大きな利点が積ん読の増加に拍車を掛けていることは明白である。というわけで今年は、積んでいる本を積極的に読んでいきたい。リーダブルコードはその1冊目。 汎用性の高い言葉 本書には、全体を通して良いフレーズがたくさん散りばめられている。その中でも、一番気に入ったフレーズはこれ。 最善の名前とは、誤解されない名前である。つまり、君のコードを読んでいる人が、君の意図を正しく理解できるということだ。 リーダブルコード (
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューガイドライン #loupestudy
プログラミングに特化した日本語Q&Aサイト「teratail」公開 