sedでこういう時はどう書く? - Qiita
シェルでデータ加工するときSEDをよく使いますが、その利用例と覚え書きです、参考になれば sedコマンドはLinux/Unix/BSD/OSXに標準で入っているので、Macの人なら覚えておくと捗るかも(Linuxとは少し違うのでそこは調べてね?) 当方の利用環境がRedhat系Linuxメインですので、微妙に書式が異なることがありますが、大体の書式は同じはずですので、そこは、ご容赦願います (4/15 ちょっと追加…) Windowsでもsed使いたいという人がいたので、ちょっと追記、以下のサイトからWindows用のバイナリを取得すれば、Windowsでもsedが使えます。WSLなどLinux環境を追加したくない、sedのコマンドだけほしい、PowerShellやプロンプトで使えればいいだけという人にお勧めです。 sed for Windows Site 使用例をいろいろ上げてみる '#
プログラマが知っておくべき、メモリ/ディスク/ネットワークの速度まとめ - Qiita
注: 無線ネットワークは干渉などによりこの数値より遅くなる状況も十分ありえます。 ポイント メモリからの読み込みとディスクからの読み込みはランダムアクセスで1000倍程度違う とは言え、最近はディスクも結構速い きちんと繋がれた有線ネットワークからの読み込みは、ディスクより速い つまり、ディスクから読むより、同じデータセンターのマシンのメモリから読んだほうが速い モバイルネットワークだと100キロバイトのデータでも1秒以上かかることがある メモリからの読込速度の遅さは、CPUのクロック数も10G/s程度なのと、本来はL1/L2キャッシュなどがあることを考えると通常意識しなくて良い 何故この参考値をまとめたか プログラミングをする際、どのくらいの時間でどのくらいのサイズ感の処理が出来るのかを考えられることが、ある一定規模以上のサービスを開発するときは必須条件になってくると思います。 なにより
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
Yarnファーストインプレッション - Qiita
Yarn とは 名前から yet another ... な雰囲気を漂わせてますが、 npm互換 です。(追記: 正確にはnpmの生成するpackage.jsonと互換とのことだった)。各所から node連中はまたツール増やしやがって！という雰囲気を感じるので、ここは明確にした方がいい。(techcrunchの記事とかそういう印象を与える書き方になってる) npm install 時のディレクトリ配置への介入 npm install 時のより賢いローカルキャッシュ yarn.lock ファイルでバージョン固定 yarn 環境下で yarn add, yarn install などを行った場合、 yarn.lock と package.json に同時に書き込み、 その環境で生成されたファイルは yarn なしでも動きます。つまり、yarn はより厳密に npm のバージョンを固定したい人向
手書きひらがなの認識で99.78%の精度をディープラーニングで - Qiita
手書きひらがなの認識、教科書通りの畳み込みニューラルネットワーク（ディープラーニング）で、99.78%の精度が出ました。教科書通りである事が（独自性がない事が）逆に読む方・書く方にメリットがありそうなので、Qiitaで記事にします。 ソースコード ソースコードは https://github.com/yukoba/CnnJapaneseCharacter です。 いきさつ いきさつは、友人と手書きひらがなの認識の雑談をFacebookでしていて、ググったら、この2つが見つかりました。 「Tensorflowを２ヶ月触ったので"手書きひらがな"の識別95.04%で畳み込みニューラルネットワークをわかりやすく解説」 http://qiita.com/tawago/items/931bea2ff6d56e32d693 スタンフォード大学の学生さんのレポート「Recognizing Handwri
黒魔術（JavaScript）まとめ - Qiita
まえがき JavaScript、書いてますか？ JavaScriptは今や世界中の人々に愛されています。 stackoverflowの2016年の調査によるとJavaScriptは地球上で最も一般的に使用されているプログラミング言語だそうです。 JavaScript is the most commonly used programming language on earth. Even Back-End developers are more likely to use it than any other language. link しかしJavaScriptは愛されすぎているが故、しばしば黒魔術のようだと比喩されることも少なくありません。 愛と憎しみが紙一重とはこのことですね。 ということでそんなこんなはどうでもいいのですが、自分もJavaScriptは大好きです。 今回は黒魔術まと
github の pull req ブランチを手元に持ってくる方法 - Qiita
Pull Request すると github 上では pull/xxx/head と pull/xxx/merge というブランチが作られる。 pull/xxx/head は Pull Request を送ったブランチの head (最新状態)、pull/xxx/merge はマージ対象のブランチとマージした結果の状態を持つブランチである。 それを手元に持ってきて操作することができる。 $ git fetch origin '+refs/pull/*:refs/remotes/pr/*' * [new ref] refs/pull/1/head -> pull/1/head * [new ref] refs/pull/1/merge -> pull/1/merge * [new ref] refs/pull/10/head -> pull/10/head ... (abbrev)
Work in ProgressパターンによるPull Requestを利用した開発フロー - Qiita
はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装
Dockerについて基本から最近追加された機能までまとめ - Qiita
Dockerとは コンテナベースのアプリケーションを仮想化したもの。軽量なVMの様に見えるがこれまでの(VirtualBoxなど)VMでは実現が難しい、不可能であったユースケースを解決してくれる。 ホストOSとリソースを共有するのでリソースの管理がVMより効率的 基本的に状態を持たないのでポータビリティが非常に高く、特定の環境に依存することがない 軽量なのでVMと比較し複数のインスタンスを実行することができる DockerHubなどのレジストリを利用することで既存のイメージをダウンロードして実行することができる コンテナとVM VM VMはハイパーバイザを通してホストOSに対してのシステムコールを解釈させるなどの必要がある それぞれのVMには全て独立したOS・アプリケーション・ライブラリが必要 コンテナ ホストのカーネルは実行されるコンテナと共有される（コンテナは常にホストと同じカーネルを
図で理解するJavaScriptのプロトタイプチェーン - Qiita
JavaScriptのリファレンスといえばMDNですよね。 JavaScriptで調べものをする際に、真っ先に見る方も多いでしょう。 そんなMDNですが読めていますか？ 例えばArrayのページを見てみましょう。 さらっと書かれているprototype JavaScriptを理解するにはプロトタイプチェーンを知る必要がある 本記事の目的 プロトタイプチェーンを理解する MDNをより読めるようにする JavaScriptのObjectやArrayなどの基本型の構造を理解する 確認環境や記述について Chrome 52のコンソールで動作確認 ES5で記述 説明のしやすさを重視、プロトタイプをあらわすのに__proto__を使って記述 まずはオブジェクトについてみていく シンプルなオブジェクトを作る
イッヌハブ をつくってみよう - Qiita
イラスト担当:嫁 イッヌハブはつくれる？ さて、なんだかQiita運営から「内容がないよう」「なので明日夕方には利用規約に基づいて削除しますぞ」と言われてしまいました。 良い勉強の機会なので、もしもこういうGitHubっぽいサービス（GitHubクローン）を作るとしたらどうやるのかな？というのをサクッと考えてデモを作ってみようと思います。 既存のGitHubクローンの実装 いぬ用に限らない汎用的なGitHubクローンは、既にいろいろな言語で出ています。 GitBucket (Scala実装) GitLab (Ruby実装) Gitonomy (PHP実装) Gogs (Go実装) いずれもオープンソースなので、少し実装を参考にしてみましょう。 Gitリポジトリーへのアクセス方法の違い これらGitHubクローンは、どうやってGitリポジトリーのデータをパースしているのでしょうか。 大きく2
初心者のためのKibanaの詳しい使い方（ダッシュボード・パネル・クエリ・フィルタの作成方法） - Qiita
この記事について 軽い気持ちで触りはじめたKibanaですが、 Kibanaについて日本語解説も少なく、設定で困った事があったのでまとめておきます。 この記事はKibanaのよく使う設定方法にのみ焦点をあてて説明します。 Elasticsearchのセットアップ方法には触れません。 また、使用したkibanaのバージョンは3.1.0です。 Kibanaとは 一言で言えばElasticsearchの検索結果をグラフ表示するツールです。 抑えておくべき事は以下の3点です。 ダッシュボードの作成方法 パネル(グラフ)の作成方法 クエリ・フィルタの作成方法 ダッシュボードの作成方法 http://${Kibanaのあるサーバ}/index.html#/dashboard/file/blank.jsonでアクセスします。 または、トップページのダッシュボードの下の方に「Blank DashBoard
PHP7.0がでたので、いまどきの「普通」のPHPの話。 - Qiita
去年のアドベントカレンダーではMongoDBの話をしましたが、今年はPHPの話。 PHPの「現在位置」 PHPが5から7へのメジャーバージョンアップをついに果たしました。(6が欠番になった経緯などは割愛) そこで、いまだに5.2とか5.3あたり、またはそれ以前の印象で語ってる人も居そうなので、改めて「PHPの普通」を確認していきましょう。 そもそもあなたPHPの何を知っていると言うんですか 今年はPHP5.6でフルスクラッチの小物サービスをリリースしましたし、古いバージョン(具体的には言えない)のサービスの保守を今も慎ましやかに続けていたりしています。 それはさておき。 いつ PHP を書きましたか？バージョンは？ 各バージョンのリリース日は以下のとおり。 - 2012/03/01 Version 5.4.0 - 2013/06/20 Version 5.5.0 - 2014/08/28
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
押下(おうか)にまつわる話 - Qiita
はじめに 私が仕様書を書くようになったのは30歳を過ぎてからと遅く、仕様書の書き方が分からなくて悩んだことがありました。通常は先輩たちが作成した仕様書等を見て書き方を覚えていくのでしょうが、仕様書も無く直接プログラムを組むような体制の仕事をしていたため、SI系に転職してから苦労したのであった。 仕様書を書く際に、ボタンを「Enterキーを押す」か「クリックする」かで考えて「押下」にすれば両方満たすだろうと、それ以来ずっと使用しています。 押下については、コンピューター雑誌やマニュアル等を読んで憶えていた用語で特に気にも止めていなかったのですが、別ブログの仲間が過去に「ボタン押下？」について書いていたことを思い出し、調べてみることにしました。 調べていくと自分は誤用して使っている気がしますw 押下について 読み方 押下は「おうか」と読みます。ちなみに苗字の押下さん(読方：おしした)は全国でお
step by stepで始めるwebpack - Qiita
※webpack1系の記事です。 1→2への移行ガイドを見る限り破壊的な変更点はそんなにありませんが、preLoadersやpostLoadersがなくなっていたり、差が出ていますのでご注意ください。 https://webpack.js.org/guides/migrating/ webpackを手を動かしつつ学べる初学者向け資料を作成しました。 公式のチュートリアルもあるのですが、webpackが使用されているOSSのボイラープレートを見る限り、世の中の使われ方に沿ってないかも？と思い書きました。 これから始める人の手助けになれば幸いです。 また最終形のソースをupしてあるので詰まったら見てください。 webpackとは webpack で始めるイマドキのフロントエンド開発の説明が良かったので引用させていただきます。m(_ _)m webpack は WebApp に必要なリソースの依
[Homekit]部屋の灯りが消えたら自動でGet Wildを再生してGet Wild退勤する - Qiita
http://qiita.com/oubakiou/items/b9b78b00906415d056b2 リスペクト HomekitではIFTTTのようにとある条件をトリガーに、Homekit対応製品をON/OFFしたり、設定を変更できたりします。 今回はPhilips Hueの電球を監視して、電球の灯りが消えたらGet Wildが流れるようにします。 Homekit対応電球を買う Philips Hue v2を買ってください。 https://www.amazon.co.jp/gp/product/B01C6S7DDU Homekit対応 Get Wild再生機器を作る getwild.mp3が入ったMacを用意します。 node.js環境をインストールします Homekitオープンソース実装の1つ homebridge と、プラグイン homebridge-cmd をインストールします
![[Homekit]部屋の灯りが消えたら自動でGet Wildを再生してGet Wild退勤する - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/a7c8e035f72aeb434a6cf7069e4deb83939a5397/height=288;version=1;width=512/https%3A%2F%2Fcdn.qiita.com%2Fassets%2Fqiita-fb-fe28c64039d925349e620ba55091e078.png)
ImageMagickとPHPを用いてPDFを画像変換する - Qiita
はじめに ■目的 ImageMagick と PHP。 そしてPHPからImageMagickを利用するためのPHP 拡張モジュールImagick。 これらを利用することでPHPスクリプトから画像変換が出来ます。 しかし、これだけではPDFから画像変換が出来ません。 そこでGhostscriptを導入しPDFの画像変換を行ってみました。 ■Ghostscriptとは PostScript/PDF インタプリタ。 よく分かりませんが、アドビシステムズのPostScriptファイルを画像ファイルに変換することが出来るもののようです。 こちらを導入することでImageMagick+PHPでPDFより画像変換が可能となるとのこと。 ■公式サイト http://www.ghostscript.com/ ■今回の実装環境 CentOS 6.5 (64bit) php 5.4.33 httpd 2.2.
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita
