技術メモ帳: [unix]複数のファイルの名前をまとめて変更する
複数のファイルの名前を変更する際に、 便利なコマンドというものがある。 いくつかご紹介させていただこう。 カレントディレクトリにあるファイルの名前を、 たとえば、*.html を *.htm と名前を変更するという課題に対し どのぐらいエレガントに書けるかというのを比較してみる。 まず、普通にやったらどうだろう。 おそらく、for文 をつかうことだろう。 for file in *.html do base=`basename $file .html` mv $base.html $base.htm; done; zshだともうちょっとスマートにかけて、 for file in *.html do mv $file:r.html $file:r.html; done; こんな具合。 for文 が嫌いなネット右翼のために、 xargs を使ってこの問題を解いてみよう。 ls -1 *.htm
RailsでWebSocketを使う - ワシはワシが育てる
タイトルの通り。 HTML5の標準規格から外されたものの、次世代に欠かせない機能の一つになるでしょう。 ただしandroidブラウザーは最新4.4以降から、IEは10以降からとブラウザ制約があるので注意が必要です。 使い方は非常に簡単です。 # gemに下記を追加 gem 'websocket-rails' # 以下のコマンドでevent.rbを生成 rails g websocket_rails:install # development.rbに以下を追加 config.middleware.delete Rack::Lock 下準備はこれだけです。 githubを見るとthinサーバーでスタートしてますが、イベント駆動に対応したサーバであれば良いのでデフォルトのWebrickでも問題ありません。 原理としては、クライアントのjavascriptとサーバサイドで先ほど生成したevent.
RubyとAWSでつくるメディアストレージ基盤 - Qiita
概要 本基盤の果たす役割としては、「利用者が本基盤に向けてファイルをアップロードし、なんらかの(変換を含む)処理を行って利用サービス側に通知する」というものになる。 そこで、想定する利用イメージを大まかにでも理解してもらうため、抽象的なイメージを図示する。 ファイルをアップロードしたいユーザーは、まず本基盤の利用サービスに対してアップロード権限の発行を依頼する。 図では省略したものの、利用サービス側はその依頼を受けて、本基盤に対してアップロードチケットの発行を依頼し、取得した情報をアップロードしたいユーザーに対して返す。 アップロードユーザーはそれを受けて、本基盤に対してファイルのアップロードを行い、アップロード・バリデーション・変換が済んだものについては本基盤が利用サービスに結果を通知するというのが大まかな流れとなる。 次に、本基盤の持つ責務について簡単に解説したい。 本基盤は、メディア
000000
これは 【その1】ドリコムAdventCalendar の1日目です *1 【その1】ドリコム Advent Calendar 2015 - Adventar 【その2】ドリコム Advent Calendar 2015 - Adventar 自己紹介 1日目：社内gemとOSSのgemのメンテについて 言葉の定義 OSSのgemのメンテで意識していること どんなに小さいgemでも自動テストは必ず書く バージョンごとにtagはpushする 読んでもらうREADMEを意識する CHANGELOG（更新履歴）を書く サンプル 粒度 カテゴリ分け CHANGELOGの半自動生成 参考になるリポジトリ gemを作ったら必ず宣伝する 社内gemのホスティングについて 社内gemのメンテで意識していること サポートするRubyやRailsのバージョンなどは社内アプリ優先 gemを作ったら社内gemとO
管理画面を開発する際に気をつけたこと - クックパッド開発者ブログ
クックパッド編集室の加々美です。 現在、食や暮らしのトレンドを発信するメディアであるクックパッドニュースの開発に携わっています。 「総合職で入社した新卒がクックパッドでエンジニアになるまで」 というエントリを投稿した2015新卒の土谷と同様に、2014年に新卒として入社後、総合職から研修を経てエンジニアへと転向しました。 今回は、クックパッドニュースの管理機能の改善を行う際に注意した点についてお話します。 自分がその管理ツールを使う人になる 事業体制の変化もあり、現状のクックパッドニュースの管理画面に関して、いくつかの運用上の問題点が指摘されており、その改善を行いました。 管理画面改善の進め方としては 「現状の業務フローの把握」「問題点の把握」「理想の管理画面の設計」 という基本的な手順で取り組みました。 現状把握と問題点洗い出しの方法としてまず思いつくのはヒアリング中心で進めていく方法で
Reactを用いたアプリケーションアーキテクチャ：Fluxを再考する | POSTD
他のフレームワークやライブラリから React に乗り換える人たちは、「ReactはUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか？」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単
リモートペアプロだけで仕事したい - komagataのブログ
今年前半はMediWebさんにいって製品コードは全てペアプロで書くという環境でやっていました。 ペアプロは疲れるけれど、コツが分かってくると、うまいやり方をすればとても有用だと知りました。 今年後半はAQさんとリモートオンリーで仕事をしました。 リモートの快適さに酔いしれました。 今やっているプロジェクトではペアプロやったりリモートで画面共有したりしてます。 ペアプロはプロジェクトリーダーにこそ有用メンバーとしての利点はいろいろ語られていますが、自分がリーダーのプロジェクトで感じたのがプロジェクトを把握するのにペアプロはとてつもなく手っ取り早いということです。 リモートワークのリーダーにとっての不安ってプロジェクトやメンバーの把握が難しい点だと思いますが、リモートペアプロならカバーできるように思います。 リモートペアプロオンリーチーム開発の全てをリモートペアプロオンリーでやるチームを作った
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コーヒー Advent Calendar 2015 - Adventar
行列日本一のとんかつを食べてきて死んだ