プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話 - Qiita
普通のプログラミング言語での開発に慣れた人ほどシェルスクリプト、特にBashで戸惑う部分の一つに、i = 0のように空白を開ければエラーになるし、かといってif[$i!=0]のように詰めてもやっぱりエラーになる、という点が挙げられます。書きたい物を思うように書けなくて「なんだよこのクソ言語は！！！」とブチギレる人は少なくないのではないでしょうか。この記事では、そのイライラを解消するポイントをお伝えしようと思います。 以下、特に断り無く「シェルスクリプト」と書いている場合はすべて「Bashのスクリプト」という意味になります。zsh等他のシェルではまた事情が異なりますので、ご注意ください。 （※以前プログラマーの君！ 騙されるな！ シェルスクリプトはそう書いちゃ駄目だ！！ という話という記事を書いたのですが、この記事は、その増補リファイン版として執筆させて頂いたSoftwareDesign 2
Vim初心者に送るカテゴリ別Vim Pluginまとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 動機 最近会社に入った後輩がVimを使っていました。 彼の.vimrcはプラグインが何も入っていない非常にシンプルなものでした。 これはしめたものだぞと、良さそうなプラグインを怒涛のように勧めまくろうと思ったのですが、 勢いのままに雑多な情報を与えては彼が混乱してしまうし、 同じような系統のプラグインであっても好みによるものが多いので 自分が使っているからと勧めるのは良くないと踏みとどまりました。 というわけで一旦自分の中でプラグインに関する情報をまとめた上で、 じっくりと彼に選んでもらいたいと思い。この記事をしたためました。 Vim以
Gitでファイルの特定行の変更履歴を追う - Qiita
> git log -L 1,10:Gemfile commit d9acf7548943f4c60be50ee43b54ce638d4d0d3a Author: kmagai Date: Sun Apr 24 18:01:22 2016 +0900 hoge -- a/Gemfile ++ b/Gemfile ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── @@ -1,6 +1,5 @@ source 'https://rubyge
Firebaseの各機能を3行で説明する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Firebase は機能が多すぎてよく分からなかったので、自分の整理用に**「 Firebase で何ができるか」**をだいたい3行でまとめてみました。 利用可能な環境かどうかは、以下のアイコンで示しています。 … Android 利用可能 … iOS 利用可能 … Web 利用可能 [追記] 新しい機能が増えたので2018/09/26時点で整理しました。 Analytics Google Analytics for Firebase イベントベースでデータ収集・分析ができる。無料。 アプリの場合は Google Analytics f
治安の悪い Slack Emoji を作るツールを作った - Qiita
(治安の悪くない Emoji も作れます) 作ったもの ここで遊べます おもしろいところ GIF アニメのエンコードまですべて js で完結しているので、ありがちな「謎のサーバーに画像アップロードするといい感じに変換してくれる」的なサービスと違って、素性の知れたコードがクライアント側でサクサク動きます。 なにができるの？ 画像を 128px x 128px に変形 画像を、 Slack にアップロードできる（現状）最大サイズの 128px x 128px に変形します。 ローカルのファイルから選ぶか、画像の URL を入力できます。アップロードするわけではないので、デカい画像でもサクサクなのがお気に入りです。 変形は 正方形に引き伸ばし（アス比無視） 正方形いっぱいに拡大して、余ったところはトリミング（アス比維持） 正方形に収まるように縮める（アス比維持） から選べます。 テキストから画像
Apollo Client + React 入門 - Qiita
こんにちは。 この記事ではGraphQLのクライアントであるApollo Clientの入門をReactをお供に書きます。日本ではVueが一番人口多いんじゃないかという気がしているのですが、Vueが人気過ぎてReactも盛り上げねば！という謎の使命感を感じているのでReactで書くことにしました。 ただ、Apollo Clientは他のUIライブラリでも利用可能で、また考え方とかは一緒なのでReact使わないという方もぜひ読んでいってください。 話さないこと 「入門」とついてるのでちゃんとGraphQLとはなんぞや、Apollo Clientとはなんぞやという点に対して言及すべきなのですが、これについては他の記事で書いたのでそちらをご覧ください。 世のフロントエンドエンジニア達にApollo Clientを布教したい バージョン情報 本記事内で使われている主要なパッケージのバージョンを記載
世のフロントエンドエンジニアにApollo Clientを布教したい - Qiita
こんにちは。いかがコーディングお過ごしでしょうか。 私は今更ながら最近GraphQLで遊び出し、そしてApollo Clientに出会いました。 ワクワクしました。「これは想像以上に既存のフロントエンドの設計・実装を変えるものだぞ！」と感じました。 「Apollo ClientってGraphQLクライアントでしょ？GraphQLエンドポイントない俺には関係ないな。」と思ったそこのあなた、それだけじゃないんですApollo Clientは！！！！！ 本記事では「Apollo Clientとはなんぞや」という話と「なぜ私がApollo Clientを布教したいのか」という点について語ります。実は最初は実装含めたチュートリアルを書いていたのですが長くなり過ぎたため記事を二つに分けました。この記事はどちらかと言うと概念系の話が多めで、片方にApollo Client + Reactのチュートリアル
Repositoryパターンのアンチパターン - Qiita
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
Webブラウザの作り方 - Qiita
この記事は何？ ほとんどタイトル通りです。 順番に読み進めていけば簡単なWebページが表示できるレベルのWebブラウザを作ることができるように執筆していく予定です。 またアルゴリズムだけをなるべくわかり易く解説していきたいので、記事内で紹介するコードは誰でも読める程度の擬似コードです。 自分で実装したい方は、面倒かもしれませんがそれぞれの言語に翻訳してください。 必要な知識としては: HTML/CSSが困らない程度に読める やる気 これだけです。 (あとこれはただの宣伝ですが、個人的にWeb ブラウザを作ってるので(http://github.com/maekawatoshiki/naglfar) スターをつけてもらえると喜びます) いろいろとパースする Webページは基本的にHTMLで書かれていますね。あとCSSも。 HTMLもCSSもそのままではただの文字列であって扱いづらいので、パー
Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
相対的なネーミングはよせ、やめるんだ！ - Qiita
たぶん1000回くらいは言われてきているがいまだに絶滅しないので、もう1回言う。ファイル名でもソースコード上の変数でもCSSのセレクタでもなんでもいいけど、相対的なネーミングはやめよう。 Safe Harbor Statement この投稿は個人の（中略）であり、所属する組織とは関係ありません。 なぜ相対的なネーミングをしてはいけないか 名前をつけた人の主観が入り込むため 時間が経つにつれ名前が実態と乖離し混乱を招くため 実装に無駄な制約をかけるため なぜ相対的なネーミングがなくならないか なにが相対的なネーミングなのか理解していないため じゃないかな多分。 避けるべき語 というわけで相対的なネーミングを回避するための禁止ワードのうち代表的なものをあげておきます。 new, 新, latest, 最新, old, 旧 など これらの時系列を表す語は、比較対象がないと新なのか旧なのかわかりま
翻訳: WebAPI 設計のベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
失敗・炎上に名前をつけることで、僕たちはもっと強く、生産的になれる。 - Qiita
TL;DR 起きた失敗、炎上には名前を付けよう。 名前を付けることで似たような問題が見えやすくなる。 名前を付けることで問題に取り組みやすくなる。 名前を付けないと、見過ごされ対策されずに過ちを繰り返す。 「要望真に受けて無事死亡パターン」という名前の力 システム開発において、ユーザ要望を文字通り実装することは、 バッドノウハウであることは、読者諸賢は十二分にご存じかと思う。 しかし、これが意外と撲滅されない。 特に若手やリーダー1年目が良くやらかすから、組織としてごくありふれた失敗事例となる。 そんなある日、 「それってよくあるパターンで、名付けて”要望真に受けて無事死亡パターン”だよね。」 という話をしたら若手から、 「そういうあるあるパターンにキャッチーなネーミングを付けて普及させたら、 失敗も減るんじゃないですかね？」 という素晴らしい提案を受けた。 ジョシュアツリーの法則 これは
Impostor Syndrome（詐欺師症候群）とQiitaについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? dev.to を見ていたら、 #impostorsyndrome というタグがあり、 #shecoded でもけっこうみんな Impostor Syndrome に苦しんでいたという記述がありました。 調べてみたら、 Impostor Syndrome （詐欺師症候群） に陥っている方は多いんじゃないかと思い、というか自分がまさに当てはまった気がしたので、エンジニアの視点でまとめてみます。 Impostor Syndrome とは wikipedia によると インポスター症候群またはインポスター・シンドローム(英: Impostor
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォータ
軽い気持ちでLinkedListを使ったら休出する羽目になった話 - Qiita
ざっくり言うと リスト構造のデータに対してランダムアクセスはしちゃだめだぞ。お兄さんとの約束だ！ 発端 数年前に他部署の支援で作ったJavaのシステムに、ちょっとデカめのデータを突っ込んだらありえないほど遅いので助けてくれ、と連絡が入った。 まぁクエリとかインデックスをちょっと見れば直るっしょ・・・と鼻をほじりながら支援に向かった。 処理内容 遅い部分の処理は以下のようなものであった。 処理対象のデータをListで受け取る。 それをforループで1件ずつ前処理する。 処理結果をオブジェクトに格納し、ORマッパーでDBにINSERTする。 これだけ？ そう、これだけだ。並列処理なんて高級なことはもちろんやってない。 インフラ調査 処理中のサーバのようすを調査する。今回のインフラは典型的な3層3サーバ構成。 WEBサーバはなにもかもが余裕。 APサーバではCPUを1つ使い切っている。 14コア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gsonで@SerializedNameって書くのやめたい - Qiita
[MySQL] "Cannot truncate a table referenced in a foreign key constraint" 外部キー制約でtruncate tableできなかった時の対応 - Qiita![[MySQL] "Cannot truncate a table referenced in a foreign key constraint" 外部キー制約でtruncate tableできなかった時の対応 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/20be8654233baf20f8fa84e6dd61d46a1e53ff03/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCTXlTUUwlNUQlMjAlMjJDYW5ub3QlMjB0cnVuY2F0ZSUyMGElMjB0YWJsZSUyMHJlZmVyZW5jZWQlMjBpbiUyMGElMjBmb3JlaWduJTIwa2V5JTIwY29uc3RyYWludCUyMiUyMCVFNSVBNCU5NiVFOSU4MyVBOCVFMyU4MiVBRCVFMyU4MyVCQyVFNSU4OCVCNiVFNyVCNCU4NCVFMyU4MSVBN3RydW5jYXRlJTIwdGFibCVFMiU4MCVBNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9ZmFlZTMwNzY1NDRiZjU5NDVjODgyZjk0YmRmNzJlMTQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBjb2xvcnJhYmJpdCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NzBlMzQ3NzE5M2IwYzI2OWE2ZWE1OTM5MmRlN2NjZmI%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dcffd2dcf2a741a260617353d69156ab8)
C++でアスタリスクをつけすぎると端末が落ちる - Qiita
