プログラマによるプログラミングのためのBGMなど、仕事や勉強の邪魔にならない無料で使えそうなBGM集。2021年版
プログラマによるプログラミングのためのBGMなど、仕事や勉強の邪魔にならない無料で使えそうなBGM集。2021年版 在宅で仕事や勉強をしている時間が増えてくると、ずっと無音だと寂しい気がして、できればあまり気にならないBGMや環境音があるといいなあ、と思ったことはありませんか？ 最近流行しているYouTubeでの24時間365日ライブ配信のLoFiチャンネルにはそうしたニーズに応えてか、プログラマがプログラミングのためのBGMを配信しているものもあります。 YouTubeの再生には動画広告が付き物ですが、ライブ配信では最初に広告が再生されると、あとは広告なしでずっと配信が続くため（少なくとも記事執筆時点では）、BGMとして使うのにぴったりです。 この記事ではそうしたYouTubeの配信を中心に、仕事や勉強のBGMとして使えそうなサービスを紹介していきましょう。 いわゆるLoFiチャンネルと
ノーコードは形を変えた現代のRPGツクールなのではないか
この記事について。 2030 年 「エンジニアです。コードは書けません。」｜__shinji__｜ note 自分はそもそもビジュアルプログラミングやオーサリングに興味があり、ノーコードは興味の範疇でありつつも、現状のもの、現状の「コード抜きで作れる」ような謳い文句は厳しいと思っています。それを、RPG ツクールを例に説明します。 はじめに、ノーコードを分類する 本記事では、「専用の管理画面で編集し、出力のためにコードを書かない、もしくはコピペ程度」のものをノーコードとして扱います。 その中でさらに種類ごとに分類してみます。このような定義があるわけではなく、自分の主観的で暫定的な分類です。 タイプ 1: データベースから自動的にフォームを生成 Google App Sheet MS Power Apps タイプ 2: 高水準 API のパイプライン Zapier IFTTT 古の Yaho
リファクタリングの際に注意すべきこと | プログラマが知るべき97のこと
リファクタリングの際に注意すべきこと著者: Rajith Attapattu 私達プログラマには必ず、既存のコードの「リファクタリング」が必要になる時がやってきます。ただ、リファクタリングをする前にいくつか考えてほしいことがあります。次に書くようなことに注意すれば、自分を含め、開発に関わる全ての人の時間と労力を大幅に節約できるでしょう。 リファクタリングするにあたってはじめにすべきことは、既存のコードベースと、そのコードに対して書かれたテストコードの洗い直しです。具体的に、現状での良い点、悪い点、強み、弱みを1つずつ確認していきます。これは、良い点、強みを残しながら、悪い点、弱みを克服することにつながります。既存のシステムに手を加えれば、必ず元より良い物になるはずと考えがちですが、実は何も良くならないこともあるし、もとより悪くなることもあり得るのです。既存のコード、テストを十分に検証しなけ
天才プログラマーの「締切に対する考え方」に、感銘を受けた。
わたしは、ビジネスノウハウ本が嫌いだ。大嫌いだ。 個人で効率化できる部分なんてかぎられているのに、「お前が努力すれば成果を出せる」的なのが気に食わない。 それなら先に、ムダな会議を減らせって話だ。 ……というひねくれ者のわたしだが、とある本に出会って、自分でもちょっと戸惑うくらい感銘を受けてしまった。 どうやらわたしは今まで、”2流”のビジネス書しか知らなかったらしい。 Windows95の基礎をつくった天才プログラマーが語る、3つの仕事術 わたしが手に取ったのは、『なぜ、あなたの仕事は終わらないのか』という本だ。 ふだんこういった本はあまり読まないけど、kindle Unlimitedで読めるし、評価が高かったから、気まぐれでダウンロードしてみた。 著者は中島聡氏。 1960年北海道生まれ。早稲田大学高等学院、早稲田大学大学院理工学研究科修了。 高校時代からパソコン系雑誌『週刊アスキー』
ラバーダック・デバッグとは問題解決手法である | ライフハッカー・ジャパン
PayPayカードのメリット・デメリット|怖いと言われる理由と評判レビュー。ゴールドと一般どっちがおすすめ?
10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しました - Make組ブログ
自走プログラマー表紙 「自走プログラマー」という本が出ます！ この本は僕と清水川さん、tell-kさんで、株式会社ビープラウドの仕事として書いた本です。 自走プログラマーには僕の10年来の開発ノウハウを詰め込みました。清水川さんtell-kさんに至ってはもっと長い経験があります。その3人が、入門本ではない本を本気で書きました。さらにビープラウドのつよつよメンバーが何度も何度もレビューしてくれました。 僕は自走プログラマーを多くの人にぜひ読んでほしいと思っています。ですが、「とにかく買ってほしい」とはあまり思っていません。 なぜかというと、普段、 僕（著者全員）が伝えたいこと・伝えてきたことを書いた本 だからです。 なので「多くの人に読んで欲しい」、「これで助けになってほしい」と思っています。むしろビープラウドでは自走プログラマー（とPythonプロフェッショナルプログラミング）を読んでもら
ASCII.jp：教育研究家とケンカして作った子どもプログラマー向けキーボードとは？｜スペシャルトーク＠プログラミング＋
「部屋の中のゾウ」（The elephant in the room）という言葉をご存じだろうか？ 明らかに問題があるのにみんなが見て見ぬふりをしている事柄のことだ。どんな業界にもあったりするものだが、 ちょっとした対処で取り除くことのできる問題であることがままある。そうだとしたら、それを放っておくのはつまらないことだ。 一緒に子ども向けのプログラミングコンテストである全国小中学生プログラミング大会（今年は9月2日が〆切）を立ち上げたギリア株式会社の清水氏が、子どもがプログラミングで使うためのキーボードを作ったという。どんなキーボードか気になって御徒町にある同社に出かけて話を聞いてみることにした。 プログラミング教室で、コードを音読したときに間違いが少ないということが重要 ―― なぜキーボードを作ることになったんですか？ 清水 ある教育研究家の方とのやりとりがキッカケなんですよ。その人は、
無料で読めるITまんが 2019年版
ネット上にはたくさんのIT系のコンテンツがあふれています。そのほとんどは文章として書かれていますが、一部にはマンガの形で面白く分かりやすくしたものもあります。 ここでは、マンガ化されたITコンテンツを集めてみました。毎年夏の恒例企画、ITまんがの2019年版です。 今年のトピックは新着マンガの1つ目と2つ目で紹介している、AWSとレッドハットが自社製品の解説をしているマンガです。企業向けのビジネスが中心のこの2社がマンガという手法を使ったことは注目に値するでしょう。また3つ目と4つ目で紹介している、すがやみつる氏のマンガは懐かしい思いで読む読者も多いのではないでしょうか。 もしここに掲載していないITまんがをご存じでしたら、Twitter（@publickey）などで教えてください。毎年更新する予定です。 2019年版の新着ITまんが New! 七転び八起きのAWS開発日記 新米プログラマ
レビュー前に直して欲しい日本語の問題点８つ - Qiita
私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○を修正した」の方が直接的です。 こんな指摘を新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。どうも、プログラマー（と言うか理系？）には独特の言語文化があり、みんな同じような分かりにくい表現をしてしまうようです。 「レビューを依頼する前にこれを読んどいて！」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった（ご存知なら教えてください）ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 （※コメント欄などの指摘を受け「補足」を追加） （※タイトル変更。「コードレビュー前に直して欲しい日
プログラマーを30年間やってきた経験から学んだことまとめ
プログラマーにとって「どうすればより効率よくプログラムを組み上げられるのか」は常に頭を悩まし続ける問題の1つとなっていますが、その道のエキスパートであるエンジニアのジュリオ・ビアソンさんが30年間ソフトウェア開発に携わってきた経験から学んだことについてブログにまとめています。 Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development) https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/ ビアソンさんは多数ある「学んだこと」を以下の3つに大きくわけてまとめています。 ◆ソフトウェア開発について ◆チーム・仕事について ◆個人的なことについて これからプログラマーになろうとしている、あるいは
プログラマーの格言（盗作多し）
プログラマーの格言（盗作多し） 頼む、９６になるまで盗作を続けさせてくれ プログラマーの格言（盗作多し） 一日は２４時間ある。 今日中という意味は明日の朝までという意味である。 プログラマーの格言２（盗作多し） プログラムは思った通りに動かない。書いた通りに動く。 プログラマーの格言３（盗作多し） 要求仕様はプログラム完成後に完結する。 基本仕様は完成品を顧客が見てから決定される。 詳細仕様は使用者がプログラムを動かしてから固まる。 プログラマーの格言４（盗作多し） 私は、ソフトウェア設計には 二つの方法があるという結論に達した。 一つは、欠陥がないことが明らかなほど単純にする方法である。 もう一つは、明らかな欠陥がないほど複雑にする方法である。 C.A.R.Hoare プログラマーの格言５（盗作多し） コードは開発現場で書くんじゃない！ 納品先で書くんだ！ デバグは納期前にするんじゃない
あなたはDRY原則を誤認している？ - Qiita
DRY原則。 WebフレームワークRuby on Railsが基本理念のひとつとして採用している有名なソフトウェア開発原則です。素晴らしい原則なのですが、最近Railsを始めた人や新卒のエンジニアさんなど、DRY原則を誤認してしまう人が非常に多い為、DRY原則に関する説明をQiitaにまとめておくことにします。 よくある間違った認識 DRY原則を誤認しているとはどういうことなのか？最も多いのが「DRYとはコードを重複させないという意味である」と認識しているケースです。当然、コードを重複させないという部分もDRYの一部ではあるのですが、これではソースコードだけに着目しているので、OAOO(Once And Only Once)原則に近い考え方になってしまいます。 OAOOとは何か 厳密な定義を書かないと斧が飛んできそうですが、長文になってしまうのであえて一言で説明すると、「コードを重複させな
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラマーの方に質問です。正直、1日8時間も集中力続かなくないですか？
FJORD BOOT CAMP（フィヨルドブートキャンプ）
ドメインオブジェクトとユースケースの関係について | プログラマーの外部記憶箱