Linux 作業手順書からべた書きパスワードをなくすシンプルなアイディア - Qiita
※ 2018/07/21 追記。 お読みいただきましてありがとうございます！ すみません、実はタイトルの割には「現在回しているイケてない運用をちょっとした工夫でサクッと改善する」ことを主眼としており、セキュリティのベストプラクティスではありません。。。 本稿の例で挙げているコマンドのリスクにつきましては、 注意 の項を追加しましたのでご参照ください。 公開当初は「10いいねくらいもらえたら嬉しいなー」と思っていた程度だったのですが、まさかここまでたくさんの方に読んでいただけるとは。。。 もっと内容を精査しておくべきだったと反省しております。。。 いいねやコメント等反応頂けるのはとても励みになります。ありがとうございます！ TL;DR 怖いですよね、セキュリティインシデント。 インフラ系でお仕事をしていると、 Linux にログインして操作する手順書を作る事が多くなります。手順書の中には認証
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
マサカリの起源について - Qiita
はじめに 技術的な指摘をすることを「マサカリを投げる」と呼ぶ。ネットスラングにありがちだが、この言葉の意味は常に変動しており、地域、人によっても定義が異なる。現在では、何か自分で詰めが甘いことを書く時に「修正、批判コメント歓迎」の意味で「マサカリをお願いします」と言ったり、誰かが適当なことを書いてコメントやブコメで炎上している時に「さっそくマサカリ投げられてて草」というような使われ方をしているようだ。 この「マサカリ」という言葉がいつ、どのような形で使われるようになったのか、できる範囲で調べてみた。 2006年以前 僕は1990年代の後半から2000年の前半にかけて、Niftyのフォーラムや、いくつかの技術系メーリングリストに登録していたが、当時この意味での「マサカリ」という言葉を目にした覚えがない。とりあえず当時所属していて、現在過去ログが見られるDelphiやBCB-MLの過去ログで検
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
食べられないほうのカリー化入門 - Qiita
『カリー化』(Currying) という概念をご存知でしょうか。"Curry" は食べ物のカレー(Curry)と同じスペルですが、ここでいう Curry はそれとは別のもので、多くのプログラミング言語に応用できるかもしれない、とても便利かもしれない概念です。 では教えてくれ。”カリー化”とはなんのことだ？ 『ふたつの引数のうち、大きい方の数を返す』という機能を持った関数 max を実装したいとしましょう。そのようなとき、大抵は次のように定義すると思います。 この関数 _max も『大きい方の数を返す』という機能を持っていますが、_max は max とは呼び出し方が少し異なります。たとえば、_max で 1 と 2 のうち大きい方を求めるには、 _max(1)(2) のように書きます。 _max が通常の max と異なるところは、関数を呼び出すときに引数をひとつづつ渡すようになっていると
偉大なコーダーが推奨する技術書まとめ - Qiita
Javascriptの生みの親であるブレンダン・アイク，memcachedの作者ブラッド・フィッツパトリック，Haskellの設計者であるサイモン・ペイトン・ジョーンズ，Googleの研究本部長であるピーター・ノーヴィグなど多くのコーダーがドナルド・クヌースの『The Art of Computer Programming』(TAOCP)を読むべき本として紹介しました。 ケン・トンプソンのおすすめ本はシンタックスとセマンティクスだけを提示する本ということですが，「言語仕様」のことでしょうか・・・。 The Art of Computer Programming クヌースは自身のTAOCPについてこう述べています。 私の本のどの5ページを取っても誰かの一生涯分の研究になっている 要は「簡単には読めないぜ」と。 実際に上記の偉大なコーダーたちでさえもTAOCPについては興味のある部分のみを読ん
新人プログラマに正月休み中を使って読んでみてほしい技術書をセレクトしてみた。 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 今年、書いた幾つかの記事のタネ本であったり、新卒教育の際に参考書籍としてあげたものを中心にリストアップします。一応amazonへのリンクも貼っておきますが、先輩が持ってたりすると思うので、冬休みに借りて一気に読んでおくのもいいかと思います。 その時々、必要な技術の習得に日々追われているんじゃないかと思いますが、いつまでも使
facebook/flowファーストインプレッション - Qiita
前々から出すよ出すよ詐欺してたflowがやっと出た。大雑把にはfacebook製のTypeScriptだと思っていれば良いです。 まだnpmで提供されてなくて、 Flow | Getting started with Flow で実行バイナリが配られてる。 npmで提供されてない理由は、たぶんocamlで書かれてるから。Future Planにjs_of_ocamlでコンパイルされたものが提供されると書いてあった。 DLして適当なパス通った場所に置いてつかう。 TypeScriptとの比較 思想はTypeScriptと同じなので、大枠は一緒だといってよい。 ぱっと見気になったのは、Nullableの書式が違うのとかあるけど、もっと大きな違いもたくさんある。 FlowとTypeScriptにあるもの declareキーワードによるアノテーション ES6 classes Generics ここ
cloudBitとIFTTTで「おとうさんいまどこメーター」を作る - Qiita
うちの息子（９）はいっつも「おとうさんいつ帰ってくるの？」と聞くそうだ。そんな息子のニーズに応え、おとうさんいまどこメーターを日曜工作で作ってみた（最初は天気予報メーターにしようと思ったけど息子にいらんと却下された）。 スマホのWiFiとGPSの位置情報をIFTTTで拾ってcloudBitでサーボを動かす簡単なしくみ。電子工作の経験は不要で、こーいうのを子どもでも誰でも30分くらいで作れてしまう。cloudBit is AWESOMEである。 以下、このメーターの作り方を簡単にまとめ。 littleBitsって？ まずはlittleBitsを知らない人のために簡単に紹介しておこう。littleBitsは子供が遊びながら電子工作を学べるおもちゃで、ボタンやLED、モーター、光センサーといったいろんな電子部品のモジュールを組み合わせて回路を組める。電子工作っても、難易度はパズドラより低い。モジ
SwiftのArrayがヤバくなくなった - Qiita
概要 思ったよりバズったので、いくつか加筆修正しました beta3でArrayの型指定の方法が変わったなーと思って眺めていたら、もっと根本的な変化がありました。 SwiftのArrayがヤバイなどで話題になってたやつです。 公式ドキュメント The Swift Programming Language 変更点 Array in Swift has been completely redesigned to have full value semantics like Dictionary and String have always had in Swift. This resolves various mutability problems – now a 'let' array is completely immutable, and a 'var' array is complet
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
Qiitaの話を聞いている - 西尾泰和のはてなダイアリー
Qiitaとブログの違いがわからないと思ってたがだいぶ違うってことがわかった ブログでは記事に間違いがあった時にコメントで指摘して著者が修正するしかないが、Qiitaではプルリクエストを投げられる(投げてくれるかどうかわからないけど) 間違いがあって修正した時に、その記事を「ストック」している人に変更通知を飛ばすことができる Kobitoってアプリがあってローカルでリアルタイムmarkdownプレビュー Kobitoなら画像のアップロードもドラッグドロップでよい、Gistでは面倒 Emacsで編集してKobitoでリアルタイムプレビューも可 投稿データをJSONでダウンロードできる、他人のも テンプレートを作れるので社内Wiki的に同じフォーマットで複数の人が書く場合に揃えるのが楽 コメントを書いたりするのにgithubやQiitaのアカウントが必要なので非エンジニア避けになる 外に見えて
静的解析に引っかからなかったメモリ破壊の話 - Qiita
リセットされるカウンタは g_loop_counter です。 いったい何がいけないのか、わかりますか？ mapファイルで確認すると、g_loop_counter は g_is_error_flg の次のアドレスでした。 ステップ実行して g_is_error_flg = false; で g_loop_counter に 0 が書き込まれるのを確認できました。 ただ、g_is_error_flg = false; の何がいけないのか、しばらくは分かりませんでした。 mogemoge.c から見ると、g_is_error_flg の宣言はどっか別の所にあって、mogemoge.c 内では unsigned int として扱うしかない訳です。 ところが、アドレスの割り付けとしてはg_is_error_flg と g_loop_counter で１バイトずつでしか割り当てられていない訳で。 困
Register UnderflowというWebサービスを作ってみました
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 GW明けにリリースしようと思っていたのですが、ぼちぼちtwitterで情報が流れだしているので、隠していても意味ないということでリリースしました。SNSやコミュニティとはなんぞや、という事について勉強がてら作ってみました。 Register Underflow どういうコンセプトのサイトかというと、大体ここに書いた通りなのですが、再度本エントリでも書いておきます。 Register Underflowについて このサイトは、SNSの普及で日本でのコンピュータやインターネット技術情報が分散してしまっている事を危惧し、かつての掲示板のように簡単かつ気軽に一つの場所で技術情報をある程度まとめた方が効率良いと思って気まぐれにたてた技術情報共有サイトで
【まとめ】これ知らないプログラマって損してんなって思う汎用的なツール 100超 - Qiita
2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマーク数が多いものを選びました。 知らないツールもあるので、分類がいいかげんなところもあると思います。何か気づいたらコメントください。 解説が不十分なツールについても、補足（コピペで本文に取り込める体裁だとありがたい）を頂けると助かります！ 元ネタの投稿は現在進
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bashでmemcachedを実装しました！ - Qiita
https://qiita.com/tokomakoma123/items/a33feffe947a958a2d3a