タグ

ブックマーク / qiita.com (263)

  • did_you_mean 1.1.0 でやってきた8つの大きな変更 - Qiita

    Kaminari 1.0.0 でやってくる5つの大きな変更の次は did_you_mean gem だ。 2017年が始まって既に10日経つが、Rubyist にとって 1月は新しい Ruby のバージョンがリリースされた直後である。仕事で開発しているアプリケーションを新しい Ruby のバージョンへ更新しようという人も多いのではないだろうか。 did_you_mean gem もクリスマス前に新しいバージョン 1.1.0 をリリースしており、Ruby 2.4.0 では新しいバージョンがバンドルされている。そこで、バージョン 1.0.0 からの変更点を振り返ってみようと思う。 実際には、1.0.0 との後に 1.0.1 と 1.0.2 がリリースされているが、これらのバージョンは明示的に gem update を実行しない限りインストールされないので、それらの変更も含めて紹介したい。 バー

    did_you_mean 1.1.0 でやってきた8つの大きな変更 - Qiita
    key_amb
    key_amb 2017/01/11
    v1.1.0 は Ruby 2.4 以上でのみ動作、と。
  • Googleの肩に乗ってShellコーディングしちゃおう - Qiita

    はじめに GoogleさんがShellスタイルガイドを共有していたので、いくつか気になった点をピックアップしました。 自分のShellスタイルはかなり我流なので、自省の意味も込めてコメントも併記します。 Googleスタイルガイドの元ネタ (Python/C++/Java/Rとかだけでなくdocumentガイドなど色々あります) https://github.com/google/styleguide Shellスタイルガイド (今回はこちら) http://google.github.io/styleguide/shell.xml 当は人間がチェックするのではなくcpplintのためXML定義なのかもですが、気にしない気にしない。 (見たところcpplintc++だけだと思ってます) commitフックでshell系のlint走らせろっていうのが今風なのかもしれませんが、キニシナイキ

    Googleの肩に乗ってShellコーディングしちゃおう - Qiita
    key_amb
    key_amb 2017/01/09
    既視感のある記事
  • 割りと便利だけど微妙に忘れがちなbashのコマンド・チートシート - Qiita

    自分用にメモしておく コマンド実行 CMD1; CMD2, CMD1 && CMD2 ;はCMD1の結果に関わらずCMD2も実行される &&はCMD1の結果が正常な場合のみCMD2が実行される CMD1 || CMD2 - 失敗時に後続コマンドを実行する CMD || printf "%b" "MSG"でエラーメッセージを表示する エラーメッセージ表示後exit 1したい場合 = CMD || { printf "%b" "FAILED.\n" ; exit 1 } CMD || printf "%b" "FAILED.\n" ; exit 1と波括弧無しで書くと期待通り動作しない(CMDが成功時もexit 1してしまう) CMD & - バックグラウンド実行 CMD &で[1] 4592のようにジョブ番号とプロセスIDが表示される killしたければkill %ジョブ番号 か kill

    割りと便利だけど微妙に忘れがちなbashのコマンド・チートシート - Qiita
    key_amb
    key_amb 2017/01/08
    けっこうなボリューム
  • JavaScript初級者のためのコーディングガイド - Qiita

    JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、JavaScriptの難易度は12ぐらいあると思います。このコーディングガイドはそんなJavaScriptの深みに嵌まらないようにするためのJavaScriptの書き方を規定したものです。初級者1のための物ですので、わかってやっている人に好きにやってください。 このコーディングガイドは絶対に従わなければならないものではありません。私は一切強制はしませんし、初級者が従わなければならないという義務もありません。採用するしないはみなさんの自由です。 禁止編 JavaScriptには安易に使用してはいけない機能があります。下記の機能は、**それぞれの機能を使っても良い、または、使うべきであるという理由を説明できない限り、**使用してはいけません。 ==、!= ==と!=を使用してはいけません

    JavaScript初級者のためのコーディングガイド - Qiita
    key_amb
    key_amb 2017/01/03
  • https://qiita.com/itckw/items/ff079c7572d6a1acd349

    key_amb
    key_amb 2017/01/02
    衰退はしなさそうだが、主要開発者の1人がだいぶ場を掻き乱している風
  • ほころびていくコミュニティとなかなかできない世代交代、そしてさよならアドベントカレンダー - Qiita

    追記: 以下の文章に対して佐藤広生先生が自らの体験に即した意見を述べておられます。ぜひ一読をお勧めします。 昨年2015年にjp.freebsd.orgドメインの終焉に伴い地域技術コミュニティの役割というポエムを書いた。今年のはその続編である。こんなポエムを書くのも今年で最後にしたい。 51歳を越えたオッサンがPort maintainerをやる状況 今年2016年は初めてFreeBSDのPort maintainerになった。devel/git-lfsとjapanese/dbskkd-cdbの2つについてである。どちらも自分の仕事に必要だったが、前のmaintainerが作業をしないままか、あるいは他の事情でmaintainer不在の状態になったか、という事情からである1。 Port maintainerをやること自身には異存はない。日にもTeXLiveのPortsを仕切っておられる佐

    ほころびていくコミュニティとなかなかできない世代交代、そしてさよならアドベントカレンダー - Qiita
    key_amb
    key_amb 2017/01/02
    読んだ。「コンピューティングはポップカルチャー」か。長期的な課題なのかも。
  • いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita

    さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分

    いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita
    key_amb
    key_amb 2016/12/26
  • MySQLのMyRocksストレージエンジンの話を中の人から聞いた - Qiita

    この記事はfreee Engineers Advent Calendar 2016の...っと、もう空きがないじゃないか! というわけで、急遽MySQL Casual Advent Calendar 2016の16日目としてお送りします。 MySQLエキスパートであるところのFacebook 松信嘉範さんによるMyRocks紹介プレゼンを聞く機会に恵まれたので、人の許可を得てその内容を公開します。 経緯 松信さんと自分は以前に同じ会社で働いていた元同僚で、彼のデビュー作「現場で使える MySQL」の元となったDBマガジンの連載時にちょっとお手伝いした縁もあり、その後も交流が続いております。 今回は松信さんがちょいと日に寄るというので事に誘ったのですが、ついでなので私の現職 freee株式会社のオフィス見学に来てもらい、「せっかくだから何かしゃべって」という図々しいお願いをしたところ、

    MySQLのMyRocksストレージエンジンの話を中の人から聞いた - Qiita
    key_amb
    key_amb 2016/12/25
  • Linuxの不揮発メモリ対応について - Qiita

    (2019/6/12追記) 今なおこの記事を参照してくれる方がいらっしゃるのですが、現在は以下のスライドのほうが情報が新しいです。 記事は残しておきますが、新しい情報はこちらをご参照ください。 https://www.slideshare.net/ygotokernel/nvdimmlinux-137104084 はじめに Linux Advent Calendarの24日目の記事として不揮発メモリの状況について記載したいと思います。今回はkernelのソースの中とかのあまり技術的に深いところは突っ込まず、概略レベルです。(深いところはまだまだ勉強中の身です)。間違いなどがあればご指摘いただけると幸いです。 不揮発メモリとは これまでPCやサーバなどで主記憶装置といえば、電源を停止させたり再起動させるとデータがクリアされる揮発性のRAMが使われて来ました。この主記憶としてのメモリが不揮発

    Linuxの不揮発メモリ対応について - Qiita
    key_amb
    key_amb 2016/12/25
    これまで揮発性だったものが不揮発になることで便利になるように見えて、実際には色々な技術的困難がある、と
  • 怪我する前に知っておきたい片手プログラミングのはじめ方 - Qiita

    私はふだん両手でプログラムを書いています。 ですが人生何があるかわかりません。 大なわ跳びで途中から縄に入ろうとして転倒し手首を骨折することもありえます(実体験)。 予定外に片手が制限されても、もう片方の手を使って変わらないパフォーマンスを出すことができれば、 それは現代の職業プログラマーとしての大きな強みになるでしょう。 この記事では、これから片手プログラミングをはじめたい方に役立つ情報を 実体験をもとに書いていきます。 片手で高速タイピングする方法 片手でプログラミングするにあたり、最も大きな壁となるのは タイピングのしにくさ です。 世の中のキーボードは基的に両手で使うように設計されており、 片手ではどうしてもタイピング速度が出ません。 この問題にはいくつか解決策が考えられます。 気合で頑張る 訓練により、通常のキーボードでもそこそこの速度でタイピングできます。 しかし、どうしても

    怪我する前に知っておきたい片手プログラミングのはじめ方 - Qiita
    key_amb
    key_amb 2016/12/25
    有益な知見だし、面白い。
  • 至高のDockerイメージ生成を求めて - Qiita

    稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ

    至高のDockerイメージ生成を求めて - Qiita
    key_amb
    key_amb 2016/12/22
  • 府大生が趣味で世界一の認識精度を持つニューラルネットワークを開発してしまった論文を読んだ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Deep Learning Advent Calendar 2016の20日目の記事です。 ConvNet歴史とResNet亜種、ベストプラクティスに関連スライドがあります(追記) 背景 府大生が趣味で世界一の認識精度を持つニューラルネットワークを開発してしまったようです。 M2の学生が趣味でやっていたCIFAR10とCIFAR100の認識タスクで,現時点での世界最高性能の結果を出したそうだ…趣味でっていうのが…https://t.co/HKFLXTMbzx — ニーシェス (@lachesis1120) 2016年12月7日 府

    府大生が趣味で世界一の認識精度を持つニューラルネットワークを開発してしまった論文を読んだ - Qiita
    key_amb
    key_amb 2016/12/21
  • 恥かどうかはともかく、そもそも逃げられない障害対応のお話 - Qiita

    システムエンジニア Advent Calendar 2016の20日目の記事だよ! 昨日は@sh-ogawaさんの「SIerが実践する分散開発とバージョンコントロール」でした!! システム障害のお話 は〜い、こんにちは!いよいよクリスマス間近ですね! この時期になると、キャッキャウフフの予定も盛りだくさんだと思います!1 そんな大事な日に限って起こるのがあれです。 そう、みなさんもよくご経験されているだろう、システム障害です2。 システム障害 それはツラく長く険しい道のりを告げるゴングです。 今回は、その障害対応のお話をしたいと思います。 この記事のアジェンダはだいたいこんな感じです。 報告する はい、システム障害が起きました〜。 キタ━━━(゚∀゚)━━━!! 「マジでか…(´;ω;`)ブワッ」 「なんで今日なんだよ〜( ;∀;)」 障害発生時の想いは人それぞれだと思いますが、まず最初

    恥かどうかはともかく、そもそも逃げられない障害対応のお話 - Qiita
    key_amb
    key_amb 2016/12/21
    確かに逃げられないが、寝落ちはあるから注意な。
  • プロダクションで2年間Redis Clusterを運用してみて - Qiita

    TL;DR Redis Clusterで運用は当に楽になった でも、Redis 4.0は不安 Redis Clusterで一番怖いのはDisk IO 特にフェイルオーバーなどのFull Resync時 Redisとは? 高速なインメモリ型のKVS シングルスレッド 豊富なデータ構造(次ページにて詳細) 豊富な操作(次々ページにて詳細) 豊富なデータ構造 key-value型 hash型(key-field-value) set型(集合演算ができる) sorted set型(スコア付きset) 任意の型(redis modules機能) 豊富な操作 インクリメントや和集合などなど lua scriptも実行できちゃう シングルスレッドだからatomicな処理になる Redisの問題点 writeがスケールしない 気軽に停止できない サーバー再起動やバージョンアップなど Redis Clus

    プロダクションで2年間Redis Clusterを運用してみて - Qiita
    key_amb
    key_amb 2016/12/20
  • Ruby の配列で n 個ずつの要素を扱いたい - Qiita

    each では要素を1つずつしか取得できないが、each_cons や each_slice を使用すればループ1回で複数個の要素を扱える。 each_cons(n) は連続した n 個の要素を1つずつずらしながら取得できる。 n = 3 [1, 2, 3, 4, 5].each_cons(n) do |a, b, c| puts "#{a}, #{b}, #{c}" end # >> 1, 2, 3 # >> 2, 3, 4 # >> 3, 4, 5

    Ruby の配列で n 個ずつの要素を扱いたい - Qiita
    key_amb
    key_amb 2016/12/20
    Enumerable#each_slice(n) で行けるんですね。便利。
  • 俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita

    ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分もで書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ

    俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
    key_amb
    key_amb 2016/12/16
  • 質問は恥ではないし役に立つ - Qiita

    一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます!なんとかなりませんか?」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ

    質問は恥ではないし役に立つ - Qiita
    key_amb
    key_amb 2016/12/14
    あっ、タイトルは逃げ恥にかけてるんですね。
  • Linux スケジューラーのコア実装とシステムコール - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに これは Linux Advent Calendar 2016 の第 11 日目の記事です。Linux のタスクスケジューラーのソースコードや関連するドキュメントなどを読んで分かったことをまとめました。とても長いです・・・ はじめにスケジューラーのアーキテクチャと重要な概念を紹介し、その後はスケジューラーコアとシステムコールの実装について分かったことを延々と述べます。調べきれなかったことや分からなかったことは TODO に残したので、コメント欄とかツイッターで教えてもらえると嬉しいです。間違いの指摘も大歓迎です。 ちなみに私が読

    Linux スケジューラーのコア実装とシステムコール - Qiita
    key_amb
    key_amb 2016/12/11
    図がすごいわかりやすい
  • 意外と知らないgoroutineのスケジューラーの挙動 #golang - Qiita

    #追記 その後GoConfernce2017で発表させていただき、その内容をまとめた記事を書いたので参考になれば幸いです。 GoConで発表してきたのでついでにruntime以下の知識をまとめていく #golang ##はじめに goroutineはGo言語の大きな特徴である並行処理を支える重要な機能です。 しかし、goroutineの仕組みについてしっかり理解しないままコードを書いてしまうと思わぬ挙動をしてしまうことがあるので注意が必要です。 今回はそんなgoroutineのスケジューリングの挙動についてまとめてみました。 僕自身がgoの書き始めの頃に引っかかった部分なので、初心者のgoroutineへの理解の助けになれば幸いです。 ##goroutineの特徴 goroutineは最小で2048byteなので、 Windows だと 1 MB、Linux だと 2 MB であるスレッド

    意外と知らないgoroutineのスケジューラーの挙動 #golang - Qiita
    key_amb
    key_amb 2016/12/11
  • 8d9bb0cfc2096c4eb8db

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? トレタ アドベントカレンダー土曜日担当の増井です。 IT芸人とは 最近、深津さんが「IT芸人」について書いていました。 一般的にIT芸人枠のエンジニアを揶揄する流れがあるけど、会社に一人はいた方がいい。IT芸人がいると、コスト0でサービスがメディアに露出し、ユーザー数万人をタダで獲得でき、求人サイト使わずに人材が募集でき、VCから1億ぐらいは余裕で調達できる上に、色んなサービスと提携しやすくなる。 — 深津 貴之 (@fladdict) 2016年11月22日 「一社に一人いた方がいい『IT芸人』」ってなんでしょう? 私が初めて「IT

    8d9bb0cfc2096c4eb8db
    key_amb
    key_amb 2016/12/11
    『その人自身がプロダクトより有名になること』が正式な(?)定義だったっけ。