朝日新聞と書くべきところを「新日新聞」――。情報番組「めざましテレビ」（フジテレビ系）のテロップ表記に、そんなミスが生じた。 これは、朝日新聞の公式ツイッターで「誤字」があったことを伝えるニュースの中で起きたものだ。「何がどうなったらこうなるんやろ」「でかいブーメラン刺さってる」といった皮肉が、インターネット掲示板などで飛び交っている。 ■平昌五輪のハッシュタグでミス発覚 朝日新聞の平昌五輪・パラリンピックのニュースを伝える公式ツイッターは2018年2月11日、フィギュアスケート男子の羽生結弦選手が韓国入りしたと伝えるツイートを投稿。平昌五輪のハッシュタグで「＃Pyeongchang2018」と付けるべきところを、誤って「＃Pyongyang2018」とした。 「Pyongyang」は北朝鮮の首都・平壌にあたるとして、ツイッター上には間違いを指摘する声が続出。同アカウントは12日夕、 「ご

mkdirしたら、すぐ移動したいのが人情というものです。 ぱっと思いつく泥臭い方法は mkdir=>C-rで履歴辿り=>mkdirを消してcd といった感じでしょうか。 ここでbashの組込み変数を使うと若干楽にできます。 今回使う「$_」には、最新のパラメータが格納されています。*1 $ valval=12 $ echo $valval 12 $ echo $_ 12というわけで、 $ mkdir /home/foo/doc/bar && cd $_とやれば /home/foo/doc/barにディレクトリを作って移動できるわけです。 参考もと bash - Is there a shortcut to mkdir foo and immediately cd into it? - Super User bash - What are the special dollar sign sh

久しぶりにcssレイアウトでハマってしまった。 floatレイアウトは一般的なレイアウトとしていろいろとノウハウが溜まっているように思いますが、flex box layoutはまだまだ思いもよらない挙動をすることがありますね。 今回ハマったのは「flex box layoutで中に長いテキストなどを含む幅可変要素のレイアウト」という一言にするとよくわからない感じですが… 要は２カラムレイアウトで、片方は固定幅、もう片方は可変幅の（幅いっぱいになるような）カラムレイアウトであり、可変幅の方の子要素として長いテキストを含んでいるもののレイアウトです。 単純に考えて↓こんな感じで書けば、１つ目の要素が幅100pxの固定になり２つ目の要素が残りをエリアの幅になると思うのですが、そうはなりません…。 <style type="text/css"> .flex { display: flex; wid

そのようすを見たTwitterユーザーが「吉野家コピペ」の改編を投稿。「今の世代には通じない」など話題になりました。 そもそも「吉野家コピペ」とは吉野家コピペとは、17年前の2001年に流行したテキストのこと。ブログが一般的になるよりも前に、ネットには「テキストサイト」と呼ばれる、文章だけをアップする個人のホームページが流行していました。 そのうちのひとつで公開されたこの文章は、その特徴的なリズムから一躍大人気に。当時のネットの雰囲気を象徴する文化のひとつとされています。 以下、吉野家コピペの全文です。 昨日、近所の吉野家行ったんです。吉野家。 そしたらなんか人がめちゃくちゃいっぱいで座れないんです。 で、よく見たらなんか垂れ幕下がってて、150円引き、とか書いてあるんです。 もうね、アホかと。馬鹿かと。 お前らな、150円引き如きで普段来てない吉野家に来てんじゃねーよ、ボケが。 150円

()+ []! JSFuck is an esoteric and educational programming style based on the atomic parts of JavaScript. It uses only six different characters to write and execute code. It does not depend on a browser, so you can even run it on Node.js. Use the form below to convert your own script. Uncheck "eval source" to get back a plain string. Encode Links Share on Twitter View source on GitHub Follow @aemke

告白されたときのステータスコードの返しかたに関するエントリが話題になっている。告白なんてそんな希有な事象には縁遠いが、仕事は良く振られるなあなんて思ったので便乗エントリ。思いついて即UPなのであまり練られてません。 100系レスポンス 100 Continue 「詳細について聞かせてください」 101 Switching Protocols 「聞くから、このメールだけ送らせて」いやここで割り込まれるとメールを送るのを忘れてしまうので。 102 Processing 「今やってます」なお、そば屋の出前の応答と同じく、本当にやっているかどうかは不明である。 200系レスポンス 200 OK 「了解しました」 201 Created 「タスクカードを新たに作ります」タスクカードはあまり長続きしないなあ。 202 Accepted 「あー、そのうちやっときます」とりあえず、新たな仕事が振られたこと

今日は秋らしいよいお天気だったので、それとは特に関係なく今日も今日とてぼーっとディスプレイに向かっていたところ、こんな記事を見付けた。 勇気を出して告白！ その返事で覚えるHTTPステータス・コード あらあらまあまあ。なんだか俺、この記者の方にシンパシーを覚えるよ。 この手のネタは大好物なのだけど、404はお断りの返事ちゃうやん、てか断り方だけでも何パターンもあるんやで、とうずうずしてきたので便乗して考えてみることにした。例によって400系レスポンスに偏ってるのはお約束。しかたないよねー。告白のレスポンスなんて受けとる方でも返す方でも400系しか知らないもん。ごめん嘘だ。503（「お前本当にタイミング悪いな」）返したことある。再リクエストはありませんでした。200？ああ、そんなステータスコードもありましたね。おいしいのかな。使ってみたいです。 （予想外に反響があったので追記）見ての通り全部

Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応

コードレビューをしてると「なんじゃこりゃぁ！？」というコードにまれに出くわします。 既存のコードとの兼ね合いでなってる場合は、致し方無くても、新規コードまで真似するのは良くないですよね。 そろそろ新人エンジニアの中には「はじめてのこーでぃんぐ」をする人も現れるのではないでしょうか。 そんな時、参考にするのは当然、既存のコードでしょう。でも、果たして既存のコードは真似するべき綺麗なコードでしょうか？ というわけで、私がレビュー時に良く注意する点をアンチパターンとしてまとめてみました。 ちなみに私はWeb屋さんなので、業界違うと微妙に違うところもありそうですけど、本質的なところは変わらないと思ってます。 パターンの名前は一般的なのをWikipediaから引っ張ってきたり、自分で思いついたのを適当に書いたりしています。 太っちょメソッド 名前のとおり大きすぎるメソッドを作るアンチパターンです。

アクセスすればすぐに本が読める URL をメールや SNS で共有したり、 ブログやウェブページに EPUB を貼り付けることができるようになるのです。

悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 コードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、現役エンジニア・池田 惇さんの経験とともに考えてみます。 アプリエンジニアの池田 惇（いけだ・じゅん／@jun_ikd）です。 コードレビューとは、エンジニアにとって毎日発生する作業であり、「コードを書く」という行為と等しく重要なタスクの1つです。同時に、ただ漠然と「粗探し」をするだけがレビューの目的ではありません。特に若手のエンジニアにとっては、先達のエンジニアのコードにじっくりと触れ、学びを得て、さらにチームに自分の持つ知識・技術を還元する、大事な機会でもあるのです。 今回はコードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、私自