初心者プログラマが犯しがちな過ち25選 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 以下はThe Mistakes I Made As a Beginner Programmerの日本語訳です。 The Mistakes I Made As a Beginner Programmer 初心者プログラマが犯しがちな間違いと、それらを特定し、避けるための習慣を学ぶ方法。 まず最初に言っておくことがあります。 この記事は、誤りを犯すことを悪いと糾弾するために作成されたものではありません。 むしろ貴方が誤りに自ら気付き、あるいはその兆候を見いだし、それらを避けられるようにするために書かれたものです。 私は過去これらの誤りを犯し
「Qiitaのユーザー名に3桁数字を使うときの注意」とその後 - Qiita
（追記）Qiita側での修正リリース完了 こんにちは。元 @500 です。 Qiitaのご担当者様から、当該ユーザー名を取得出来ないようにする修正リリースを11月19日に行ったと連絡を頂きました。 同時に、ユーザー名の変更依頼を受けましたので、 別のユーザー名に変更し今に至ります。 この記事をご覧になった方からいろいろな意見が来ていましたので、11月12日時点の記事内容に加筆をして以下に残します。 その出会いは偶然に…… なぜか空いていた「短いユーザー名」 これまで備忘録はiCloudのメモに書いて同期していたのですが、今さらQiitaに記事を書こうと先ほどアカウントを作成しました。 私は特に共通のハンドルネームみたいなのもなく、各種サービス登録時には超適当にユーザーIDやユーザー名を決めるタイプです。 Qiitaでは3文字以上とあったので、適当にユーザー名500と打ってみたら、意外にも一
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまで - Qiita
「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまでC#DIDependencyInjection依存性の注入 DIはインタフェース定義しなくても十分実用的だし、むしろそっちの方が本質だよ、という話をします。C#や.NETを使っていますが、それに限らず普遍的な内容です。 インタフェースと実装に分けるとか無理。DIなど不要！ 中堅社員のA氏は、**「DIっていちいち実装とインタフェース分けないとダメなんでしょ？。さすがにやってられんわ」**と言って頑なにDIを導入しようとしません。 DIはテスタビリティと併せて語られることが多かった為か、A氏は「注入するクラスは基本的にインタフェース定義しましょう」という記事ばかりを読んでいたのです。 インタフェースと実装を分けるとは、例えば次のような事です。 services.AddSc
エンジニア200人に聞いて、業務委託単価表を作りました - Qiita
ISSUEへ移動しました 診断機能の結果も元に単価表の精度をアップデートしています。購読してお待ちいただければと思います。 2022年度最新版はこちら こちらの単価表を元に単価診断機能を作りました 様々なご要望を受け、新たに単価診断機能を作成しました！質問形式で現時点での単価目安を診断することができます。改良に改良を重ねていくのでぜひ一度受けてもらえると嬉しいです！ はじめに 私は「ISSUE」という副業プラットフォームを運営しているのですが、プラットフォームを構築する際にエンジニアの方々約200人とお話しました。そのヒアリング内容からエンジニア業務委託単価表を作成してみました。単価はこれから副業やフリーランスとして活動しようという方々がよく悩むところだと思います。私もそうでした。またすでに業務委託をしている方もどのタイミングで単価を上げる交渉をすればいいかとても悩むものだと思います。そん
マジックナンバー使うな? どんどん使え! - Qiita
マジックナンバー使うなって言われません? 私も昔はそう思ってたんですよ。 そうでもないなあと最近思い始めたわけでして。 よくある「マジックナンバー使うな!」 消費税の税額を求めるプログラムがあるとします。(軽減税率とかいろいろありますが、面倒なので一律 10% ってことにします)
総当たり攻撃時のパスワード最大解読時間の表(by 上野宣)について分析した - Qiita
昨日、上野宣（@sen_u）さんがパスワードの総当りに要する時間の表をツイートされ、話題になっています。 総当たり攻撃時のパスワード最大解読時間の表を日本語化した。https://t.co/cVSNUZkAKv pic.twitter.com/rtS8ixwOqi — Sen UENO (@sen_u) August 17, 2021 1万件を超えるリツイートがありますね。大変よく読まれているようです。しかし、この表は何を計測したものでしょうか。上野さんにうかがってもわからないようでした。 何ですかね？パスワード空間が大きくなると解読に時間が掛かるということくらいがわかりますかね。 — Sen UENO (@sen_u) August 17, 2021 一般に、パスワードの総当たり攻撃（ブルートフォースアタック）というと、以下の二通りが考えられます。 ウェブサイト等でパスワードを順番に試す
最初から強いやつの特徴 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに どんな仕事でも強い人は存在する。 でも最初から強い人は珍しい。 これは、web 業界に身を置いてみて、信じられないくらいムキムキになっていった人たちを見てきた私が送る こうしたら強くなれるかもしれない？指南書である。もしエンジニア職に興味があるのであれば、一考になるかもしれない。 最初から強いやつの特徴 平日の稼働時間以外も勉強 or 開発する 土日も勉強 or 開発する 公式ドキュメントをちゃんと読む 以上のような当たり前のことは、最初から強い人じゃなくてもやるので特徴に入れません。 1. 読解能力が異常に高い 国語の力です
綺麗なコミットログを作りたいときのgitテクニック - Qiita
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
１時間かかった作業が0.22秒で終わってしまった話 - Qiita
Day1 「ある日のテストで作成したデータAと別の日に作成したデータBに差異がないことを比較してほしい」と僕にタスクが割り振られた。 こんな手順でエビデンスを作った。 １．データAとデータBを抽出するSELECT文をそれぞれ実行。 ２．１の結果をcsvファイルにそれぞれエクスポート。 ３．２のcsvファイル2つをシートを分けてExcelに貼り付け。 ４．３の各シートで、抽出結果の文字列結合を各行で行う。 ５．４で文字列結合した結果が、データAのシートとデータBのシートに互いに存在するかExcel関数で確認。 データAとデータBはそれぞれ2万件程度あり、エクスポートと貼り付け作業にそれなりに時間がかかった。文字列結合や存在チェックのためのExcel関数は8万セルに及び、Excelは山のように大きく重たくなった。 この作業は気合と根性で1時間程度で終わらせた。 Day2 別の日に同じタスクが割
単一責任の原則とは何だったのか - Qiita
はてブで単一責任の原則（Single responsibility principle）について、もう一度考えるといふ記事を見掛けて、なんとなく懐かしい気持ちになった。久し振りにこの言葉を見たなって。 「一つのモノに一つの責任 (役割) を」といふモットーは、初めて聞いた時にはすごくもっともらしく聞こえるんだけど、いろいろ考へてくと結局「責任が一つであるとはどういふことなのか?」「といふか、責任って一つとか二つとか数へられるものなのか?」といふ疑念を抱くよね。俺も昔さう思ひました。 で、この菅野さんの記事では「責任が一つであるとは、一人の利用者 (アクター) に対してだけ責務を果たすこと」といふ話をしてゐる。その理解はたぶんそんなに間違ってはゐないと思ふ。ブコメに「作者の人そこまで考えてないと思うよ」とかいふコメントもあったけれども、菅野さんの記事が信用できないと思ふんならボブ本人による記
C#のORM（オブジェクト関係マッピング）における理想形を考えてみる - Qiita
はじめに C#のORマッパーといえばEntity Framework（以下、EF）が有名で、データベースの接続を調べると真っ先にEFの名前が出てきます。ORMの機能を充分に備えたライブラリはEFしかありませんが、致命的な欠点があります。欠点については後述しますが、これを解決するには他のライブラリを使うほかありません。本記事では、EFを使わずにORマッパーの機能を使うライブラリとその組み合わせを紹介します。 ORMの基本的な機能 紹介する前にまずはORMで必要な機能を確認します。ORM（Object-relational mapping）は、オブジェクト関係マッピングと呼ばれ、オブジェクト思考とRDB間の非互換であるデータの違いをうまく吸収（これの逆をインピーダンスミスマッチと言います）して、簡単にデータを扱えるようにする技法です。基本的な機能は以下があります。 SQLを意識することなくコー
こんなコードは嫌だ、古い書き方のコード駆逐したい（とりあえず９つ） - Qiita
##時代は令和ぞ、何を書いとるんや 転職してきた若いプログラマが変なコード書いている。 どうやら前社の社内研修で教わったとのこと。 さて、何を教わったのだろうか。 ※一応TypeScriptで書きましたが別にC#でも言えることです。 ※CやC++やアセンブラのことは全く知らないので、そのあたり詳しい人は今どんな書き方か記事書いていただけると勉強になります。 ##１．変数名が雑 クラス、関数、変数、どれも命名は難しいものです。1 大体が英語で大変です。けど頑張ってわかりやすい名前つけるようにしています。 本読んで勉強してください。Google翻訳使ってください。 10行程度の短い関数ならretでもdataとか適当な名前でもいいけど 長くなるようならちゃんと名前つけてるようにしたほうがいいです。 わかりやすい変数名をつけることでひと目で、その変数の役割が理解出来ます。 // Goodってなんや
「分析SQLスタイルガイド」をかなり真面目に考えた - Qiita
目次 なぜSQLのスタイルガイドが重要なのか この記事の目的 この記事の対象者 分析SQLスタイルガイドの指針 基本ルール 命名規則 インデントルール 別名ルール joinルール クエリ分割ルール ⭐ コメント欄で「いや私はこう思う！」という意見をたくさんいただきました！ぜひそちらも御覧ください！（決して揶揄ではないです） なぜSQLのスタイルガイドが重要なのか SQLはプログラミング未経験者でもとっつきやすい言語と言われ、エンジニアや分析を本業としていない人でもSQLを使う機会が増えてきていると思います。 そんなSQLですが、こちらのブログでも指摘されている通り、一般的なスタイルガイドが定まっていません。スタイルガイドとはコードの書き方マナーようなもので、どこで改行するか、空白はいくつ入れるか、大文字を使うかなどの諸々を指します。 もしスタイルガイドが無いとこんな事が起こります コードに
SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか？ 今回は、そんな方々にこそ
管理者用初期化URLを踏んでWebサービスのデータをふっとばした話 - Qiita
自己紹介 本職のエンジニアではありませんが、ちょっとICT系に詳しそうなやつって感じで、部署のサーバ管理を任されたりもしています。 背景 私の（当時所属していた）部署では、毎年、数週間かけて前年の各人の業務実績をとりまとめて一つの冊子（PDF）にするという仕事があり、この作業を少しでも自動化するため、Webサービスが内製されました。当初は単純に各ユーザが自分の業務実績一覧をテキストで用意してアップロードするというものでしたが、秘伝のタレのように毎年少しずつ改良されたり、大幅に作り直されて別システムから業務データを取り込んでからブラウザ上で編集できるようになったりしつつ、なんやかんやあって私が引き継ぎます。他にやりたい人もなく、ひとり鯖管です。OSはCentOS6でした。 このシステムでは、毎年新しいデータを編集するため、その作業開始時にデータを初期化する必要があります。この作業も自動化し、
本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita
起きた事 本番環境のデータ調査の依頼を受けた。その調査を受ける前に、それとは別で不要データを本番DBから削除する作業をMySQL Workbenchで行っていた。 本番DBで、データ調査を行う際にMySQL WorkbenchでSQLのselectと間違えてdeleteを実行してしまい、Tableを1つ丸ごとDeleteしてしまった。 ON DELETE CASCADEが親テーブルに設定されてしまっていたため、さらに4つのTable dataが芋づる式に消えてしまった。 ON DELETE CASCADEの説明としては、この記事がわかりやすかったです。 https://www.dbonline.jp/mysql/table/index11.html テーブルの構成(テーブル名などは例として挙げていて、実際のものとは多少異なります) 正しい設定 usersテーブルでuserを削除した時に、そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CentOS7にMySQLをインストールして初期設定するまで - Qiita
MongoDBインストール ～ PHPで使うまで - Qiita
「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話 - Qiita
