無料で学ぶ『達人に学ぶSQL徹底指南書 第1版』 - Qiita
はじめに 『達人に学ぶSQL徹底指南書 第1版』は、CodeZine連載とミック氏ウェブサイトの掲載記事をもとに、加筆・編集されたものです。 CodeZine連載、および、ミック氏ウェブサイトは、どちらもオンラインの無料公開コンテンツです。 今回、「書籍と元コンテンツの対応表」を作成しました。 書籍のために書き下ろされた一部コンテンツや演習問題は見れませんが、その一方、編集で割愛された内容などが含まれるので、書籍以上のことを学べる箇所もあります。 すでに新版『達人に学ぶSQL徹底指南書 第2版』が出ていますが、各テーマは第1版でも大きく変わっておらず、現在でも通用する基本的で面白い内容なので、一見の価値はあると思います。 書籍と元コンテンツの対応表 No. 目次 CodeZine連載 ミック氏ウェブサイト テーブル定義 サポートページ
【ガイド】優秀なプログラマーになるための10のメソッド
はじめに 今回の記事では、個人的に「優秀だ」と考えるプログラマーになるための10の具体的な方法を簡潔に解説する。あくまで個人の一見解に過ぎないが、今後プログラマーとして活動する上で１つでも参考になるものがあれば幸いである。 自分が使っているツールの使い方を再度確認する 自分が使っているツール(VSCodeやDockerなど)の使い方を再度確認してみよう。例えば、VSCodeの場合はショートカットキーや拡張機能を調べて自分の開発に役立ちそうなものを中心にインプットしておこう。 シングルタスクを徹底する シングルタスクを徹底しよう。要は、一つの作業に集中することである。原則として、人間は複数の作業を同時並行で進めることはできない。マルチタスクは生産性を著しく下げてしまう。例えば、動画を見ながらプログラムを書くことはマルチタスクになる。 知的労働の生産性を高めるなら、シングルタスクを徹底すること
開発生産性のカレンダー | Advent Calendar 2022 - Qiita
開発生産性の改善の取り組みなどを扱うカレンダーです。 小さなTIPSからじっくり取り組んだことまで、大小さまざま共有していければと思ってます！ 関連キーワード Four Keys（デプロイ頻度、リードタイム、変更障害率、MTTR） 「LeanとDevOpsの科学」「Accelerate」「DORA」「State of DevOps」 DX Criteria、開発者体験 継続的デプロイ、リーン製品開発、リーンマネジメント 開発生産性と職務満足度、eNPS、バーンアウト、セキュリティ、採用、経営などとの関連 開発組織文化、情報の共有、コミュニケーション、オンボーディング DevSecOps 開発生産性の可視化
安全性のヒント - Qiita
会社に属している人や事業を運営している人が、他者へ貢献すること（仕事）に意識を向けるためには、3段階目までの欲求がある程度満たされている必要がある訳です。 なので、仮に安全性が100%満たされた場合においても、帰属できている感覚や愛されている感覚が少ない、いわゆる孤独を感じている状態だと、他者へ貢献すること（仕事）に意識を向けることが難しくなると考えています。 危険や脅威を感じると他のことを考えられなくなる 欲求は、人間における生存本能に直結していると考えられます。 生存が脅かされるような何かに対しては、逃げるか避けるか戦うかの行動をする訳ですが、それによって意識(注意力)を対処すべき危険や脅威に集中するため、物理的にも心理的にも視野が狭くなり、他のことに注意を向けることが難しくなります。 危険や脅威を感じていない状態が、安全の欲求が満たされた状態と言えますが、自らの生命に直結するような危
Node.js でお手軽スクレイピング 2020 年夏 - Qiita
皆さんは Web ページのスクレイピングって書いた事ありますか？私はあります。だってどんなに平和で平穏な生活を送っていても数年に一度はスクレイピングってしたくなりますよね。「うわーまじか！API ないのかよ…。」的な。 そうしたら HTTP クライアントと HTML パーサのライブラリを探してきてインストールした上でごりごり書くことになると思います。でも実際に書いてみると、そうやってライブラリのインストールをしたりサンプルコードで動作確認している時間よりも、HTML を解析して実際にパースしたところから対象の要素を取得して欲しい値を取り出す試行錯誤の時間の方が長かったっていう事はないですか？ 今日ご紹介する Node.js でお手軽スクレイピングは、その辺の試行錯誤の手間を極力減らすことが出来る方法です。2020 年夏の最新版です。 まずは環境から。特に古いものを使う理由もないので 202
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
Qiitaにプログラマ向けの英語記事を書いたよ＆3万Contributionを達成したよ - give IT a try
お知らせ：Qiitaにプログラマ向けの英語記事を書きました Qiitaに「和英辞典・自動翻訳だけじゃダメ！もっといい英語名を見つけるためのTips集」という記事を書きました。 この記事はその名の通り、クラスやメソッドの英語名を付ける際に、和英辞典や自動翻訳以外に検討すべき選択肢を説明したものです。 シソーラスを使う方法や、画像検索で自分のイメージと比較する方法など、僕が実際によくやっているテクニックを紹介しています。 また、普段はRubyプログラマ向けの記事をよく書いていますが、この記事の内容はRubyに限らず、いろんなプログラミング言語で汎用的に使える内容になっているはずです。 ちなみに、この記事を書いた背景は、社内で同じような話をよく繰り返しているからです。 この記事は「伊藤さーん！英語の命名手伝って－！」と社内で頻繁で聞かれるので、そのときに毎回答えている内容が元ネタになっております
Kaizen Platform という会社について
Qiita:Team エントリのレベルが高い CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。 SRE （インフラチーム）のレベルが高い インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。 yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA （総務部門のドン）やってるし、 glidenote さ
Incrementsを退職します – r7kamura – Medium
IT エンジニアが退職するときに添えられることが多い東亜飯店の画像今月いっぱいで Increments 株式会社を退職します。今日が最終出社日で、残りは有給消化です。 Increments では何をやってたの？Increments と言えば Qiita を運営している会社というイメージですが、Qiita の開発に直接携わる機会はほとんどなくて、技術基盤や Qiita:Team の開発に携わったりしていました。 分かりやすい例を幾つか挙げると、Qiita API v2、トップページのフィード、通知購読、絵文字リアクション、タスクリスト、qiita-elasticsearch、qiita-markdown、アクセス権限付きグループ、サポートサイト、チーム統合機能の開発や、UI 刷新、絵文字画像セット移行、ログインセッション永続化、Docker 移行、VPC 移行、Terraform 導入、We
Qiita の Increments を退職します - mizchi's blog
4月からフリーランス。直近半年の仕事は埋まってるけど、パイプ作っときたいとかあれば mizchi2w@gmail.com までメールください。 なんでやめるの？ 要約: 自分のスキルの、ベンチャー企業の社員としてスキルミスマッチ フロントエンドの、とくにSPAで高速で堅牢なアプリを作る、という自分のスキルセットを振り返ると、「需要はあって必要なことには必要だが、どうしても瞬間風速が高いそのタイミングを超えると扱いに困る」という人材適正があると認識しており、前職のQuipperから引き続き2社連続で、「そのために入った最初のプロジェクトが終わると、やや手持ち無沙汰になる」という状態になっていました。 とくにスタートアップのような、予算が厳しい上にピボットする可能性ある現場だと、自分のスキルが活かせないフェーズがある、というのが、会社にとっても、個人のモチベーションとして厳しいものがありました
Qiitaは言論弾圧の恐怖政治をしたいらしい。
運用ご担当者様 あなた方が行っている行為は、言論弾圧や自由な発言、使い方を全否定する運営方法であって、 Qiitaの運営事務局は、いつからそんなに莫大な権限を持ったのでしょうか？ Qiitaは言論弾圧して、そこまでして恐怖政治を行いたいのですか？ 自由な場所、平等な発言の機会がインターネットの世界です。 私個人が、広告塔を貼って、利益を得ていたというのであれば話は別ですが、 普通に投稿して、広告も貼っていないので、私には利益は一銭も得ていません。 そんなに自由に使われたくなければ、インターネットの世界からQiitaは退場して頂け無いでしょうか？ 個人的な感情で、私個人を攻撃するのであれば、このカレンダーに記事を提供して頂いた他の皆さんを巻き込む 必要は無く、私の記事だけ削除なり、非公開にすればよいのではないですか？ そちらが感情的に削除や非公開を繰り返すのであれば、インターネットの自由を取
フロントエンドへの複雑化について、一つの視点 - mizchi's blog
これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記
Qiita でストックした投稿を Pocket に加える via IFTTT - Qiita
自分のストックした投稿を、IFTTT を使って pocket に自動保存しましょう。 <!--more--> Qiita のストックを「あとでよむ」的に使っていたのですが、Author さんの Contribution が消えてしまうことに気がつきました。 いろいろ申し訳ないので、Pocket と連携させます。 ストック一覧を RSS 化する IFTTT で扱える RSS 形式のデータを、RSS Creater を利用して用意します。 Qiitaのストック一覧をRSS化する方法 - Qiita [キータ] RSS Creater URL からコンバートする お使いのアカウントのストック一覧 URL を入力します。 私の場合は、このような形式です。 http://qiita.com/DriftwoodJP/stock RSS 化する範囲を指定する 編集画面に Qiita のストック一覧が現れ
クロージャってどんなときに使うの？ ～ 利用場面を ３つ 挙げてみる - Qiita
結論を先にまとめると、以下の３つです。 1. グローバル変数の宣言をなるべく減らしたい場合 2. ユーザが引数を与えてカスタマイズ可能な自由度の高い「関数」を生成したい場合 3. 前回、呼び出されて実行されたときの演算結果（値）を内部で保存して、次に呼び出されたときに、前回の結果（値）に対して、さらに同じ処理（演算）を行う関数を生成したい場合 以下、「クロージャ」の定義から、頭の整理まで、分かりやすい参考ウェブサイトへのリンクを張りつつ、見ていきます。 【 定義 】クロージャ takeharuさん Qiita記事（2013/07/22）「JavaScriptでクロージャ入門」 「自分を囲むスコープにある変数を参照できる関数」 Wikipedia 「クロージャ」 引数以外の変数を実行時の環境ではなく、自身が定義された環境（静的スコープ）において解決することを特徴とする。関数とそれを評価する環
絶対に見逃せない投稿が、そこにはある - Qiita
Qiita の 「見逃せない投稿」 を独自に評価してランキングするサービス Qaleidospace を作りました。 本投稿では、そのようなサービスを作ろうと思った理由、投稿を評価するアルゴリズム、システム構成について書きます。 余談ですが、今なら Yearly Ranking がほぼ 2015 年の投稿ランキングとなっており、眺めていて楽しいです。 TL;DR Qiita の「見逃せない投稿」をランキングするサービス Qaleidospace を作った。 適切な評価システムがあれば、書き手も読み手もみんな幸せになれるはず。 ストック数だけで評価すると、初心者向けの投稿やキャッチーなキーワードを散りばめただけの投稿が注目されやすい。誰がストックしたのかを重視して「見逃せない投稿」を評価する。 風変わりなシステム構成: GitHub Pages でホスティング + Swift で書かれたバッ
Ruby のココがダメ - Qiita
タイトルは釣りです。Ruby に盲目的に惚れている迂生には Ruby の痘痕（あばた）はエクボです。 それはともかく。 メソッド名の別名がありすぎ 「あなたは map 派？ それとも collect 派？」っていう問いがまず嫌い。 いや，別名にも意義があるとは思うんだけど，記憶の負担が大きい。 自分では map しか使わなくても，他人のコード読むんだったら collect を知っていなくちゃならない。 しばらく前に reduce っていうメソッド見て，そんなのあったっけ？と思ったら inject の別名だった。 map/collect と inject/reduce の名前とその背景にある発想については，Rubyist Magazine に良い記事がある： そうかと思えば，Array#delete_if と Array#reject! みたいに，働きは基本的に同じだけど，削除が行われなかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/advent-calendar/2016/free_zankoku
TechCrunch