タグ

開発に関するNetPenguinのブックマーク (201)

  • jq コマンドを使う日常のご紹介 - Qiita

    jq コマンドとは http://stedolan.github.io/jq/ JSONから簡単に値を抜き出したり、集計したり、整形して表示したりできるJSON用のgrepとかawkみたいなコマンドです。 WebサービスがJSONを吐いたり、AWS CLIが JSON を吐いたりする現代社会で大変便利なコマンドです。 マニュアル だいたいここ読めばOK. http://stedolan.github.io/jq/manual/ あ、これで、終わってしまう。だけど気にせず進めます。 簡単な例 まず、空気をつかみましょう。 以下jqコマンドの記法を見ていきます。JSON { "hoge": "value" } があった場合、 . がルート {} を表します。.hoge で "value" を表現します。だいたいこんな感じです。 ただの整形 しばらく下記のJSONを例に進めます。itemsには配

    jq コマンドを使う日常のご紹介 - Qiita
    NetPenguin
    NetPenguin 2017/12/20
    JSON の文字列を入力として柔軟な grep や集計ができるコマンド jq
  • 技術的負債に対峙するための「最初」と「一手間」 - 思考と現場の間で

    技術的負債の問題は全世界でおそらく課題になっていて(笑)皆さん頭を悩ませているんじゃなかろうか。私もずっとそうだ。プログラマとしてもマネージャーとしても、直接的にも間接的にも苦しめられてきた。 そんなこんなで、うまく行かなかったり多少改善したりしつつ、ドメイン駆動設計に出会って、これが突破口になるとは感じて、取り組んできたり研究したりしてきた。とはいえ、目の前の大きな負債に向かうのはモチベーションもわかないし、組織戦略としてどうするかは当に悩ましい。問題は「技術的負債」と一言で言えるほど単純ではない。組織も人もサービスもシステムもビジネスも絡まり、大きくて複雑だ。 そんなこんなで、増田さんとうなぎをべに行って、増田さんのその辺の見解を伺ったり、ディスカッションしたりしていたんだが、増田さんが木工職人の例を話しをされていたときに、 「木工職人たちは「一手間」を大事にしていた」 ということ

    技術的負債に対峙するための「最初」と「一手間」 - 思考と現場の間で
  • Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita

    記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

    Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
    NetPenguin
    NetPenguin 2017/12/20
    いろいろな記事へのリンクが豊富. 対象範囲も広い
  • JetBrains系IDEと各種ITSとGitを連携してスマートに作業する - mike-neckのブログ

    JetBrainsユーザーグループにて「IntelliJとYouTrack」というタイトルにて発表してきましたが、グダグダな発表をしたのでちゃんとまとめた記事を書きます。 jbugj.connpass.com 要点 JetBrains系IDEでは、標準に付属しているツールを用いることで、スマートに作業ができます。(なお、一部のIDEについてはリポジトリーからインストールしないといけなさそうです(GoglandにはTaskManagementプラグインが付属していないようだった)) Task Management プラグイン ITS(イシュー管理システム)とIDEを連携させてTask と Context を管理できるプラグイン Task - イシュー管理システムのチケットに該当する、作業の単位をあらわす Context - 開いているファイルのカーソルの位置や、プロジェクトツリーの開いている

    JetBrains系IDEと各種ITSとGitを連携してスマートに作業する - mike-neckのブログ
  • TBD = To Be Determined ほか - 日常、あるいは平穏な日々

    TBC(To Be Confirmed) (確認中) TBD(To Be Determined) (現在未決定だが、将来決定する) TBA(To Be Assigned) (担当者未定) TBA(To Be Activated) (要アクティベート) TBA(To Be Added) (追加予定) TBA(To Be Advised) (追って通知する) TBA(To Be Announced) (後日発表) TBA(To Be Approved) (承認待ち) TBA(To Be Arranged) (手配予定) TBB(To Be Billed) (請求予定) TBC(To Be Cancelled) (中止・取消予定) TBC(To Be Completed) (完了・完成予定) TBC(To Be Confirmed) (確認予定) TBC(To Be Considered) (検

    TBD = To Be Determined ほか - 日常、あるいは平穏な日々
    NetPenguin
    NetPenguin 2017/01/16
    TBD とか TBR とか to be 〜 の略語と意味
  • シンプルかつ美しいREST APIクライアント「Insomnia 3.0」 | ソフトアンテナ

    REST APIをテストすることができるデスクトップクライアント「Insomnia 3.0」。現在Mac/Windows/Linux用のデスクトップアプリを無料でダウンロードすることができます(Pricing Plansによると、個人用のデスクトップアプリは無償で利用できるかわりに、チーム・企業向けの有料プランが計画されているようです)。 Insomnia 3.0はChromeアプリとして公開されていたv2.0と異なり、完全なデスクトップアプリとして書き直されています。 REST APIをテストするためのクライアントアプリで、様々なHTTPリクエストを素早く組み立て、リクエストに対するレスポンスを詳細に確認することが可能です。ワークスペースを使用してリクエストを管理し、ドラッグ&ドロップで整理したり、データをインポート・エクスポートする機能も搭載されています。 APIキーのようなリクエスト

    シンプルかつ美しいREST APIクライアント「Insomnia 3.0」 | ソフトアンテナ
  • Bash Infinity Framework - シェルスクリプトの概念をはるかに超えるモダンなフレームワーク | ソフトアンテナ

    UNIXやMacを使用しているユーザーならば誰でも一度はシェルスクリプトを作成した経験があると思います。どんな環境でも使い回せるポータビリティの高さが魅力ですが、プログラミング言語としてみると独特な部分が多く、なんとなく苦手意識を持っている方も多いかもしれません。 日紹介する「Bash Infinity Framework」はそんなシェルスクリプトの概念を完全に変えてしまうBash用のフレームワークです。 モジュラーかつ軽量で、C#やJavaJavaScriptといった他の言語のコンセプトを取り入れ、プラグ&プレイで必要な機能だけを追加していける特徴を持っています。 主な特徴は以下の通りです: 自動エラーハンドリング 名前付きパラメータ($1、$2ではなくて) 配列とマップをパラメータとして引き渡せる try-catchの実装 独自例外のthrow キーワードのインポート 出力を改善す

    Bash Infinity Framework - シェルスクリプトの概念をはるかに超えるモダンなフレームワーク | ソフトアンテナ
    NetPenguin
    NetPenguin 2016/08/27
    なんだこれは!クラスはいらないと思うけど名前付き引数とかはいいなぁ
  • gitにおけるコミットログ/メッセージ例文集100

    私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ

    gitにおけるコミットログ/メッセージ例文集100
  • Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog

    綺麗にコミットしてますか?? はじめまして!Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何? Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という

    Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog
    NetPenguin
    NetPenguin 2016/07/05
    これはよさげ。試してみたい。
  • バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い

    バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
  • MailSlurper - Web管理画面を備えた開発用メールサーバ

    システム開発中においてもメール送信をテストしたいと思うことがあります。さらに番環境のSMTPサーバを設置していたりすると、ミスした時にとんでもない事態になる可能性があります。十分な注意をしなければならないのがメールシステムの問題です。 そこで使ってみたいのがMailSlurperです。ローカルで動作する、開発用のメールサーバです。 MailSlurperの使い方 MailSlurperを実行すると、Webブラウザ向けの管理画面と開発用のメールサーバが立ち上がります。 メールを送るとWeb管理画面で内容が確認できます。実際には送信されていません。日語はデコードされないようです。 設定画面です。 MailSlurperを立ち上げておいて、メールを送信するようにすればメールアドレスの確認メールやパスワードリマインダーなどのメールについてもテストしやすくなるでしょう。何より実際には送信されない

    MailSlurper - Web管理画面を備えた開発用メールサーバ
    NetPenguin
    NetPenguin 2015/11/14
    いずれ必要になった時にそなえてブクマ
  • GitHub実践入門、Pull Requestによる開発の変革。GitHub Kaigi 2014

    GitHub User Group主催のGitHub Kaigiが6月1日、都内で開催されました。GitHubを利用した開発は、スタートアップやオンラインサービス系の企業などを中心に広まりつつあり、いままさに数多くのノウハウの交換が求められているツールでもあります。 記事ではGitHub Kaigiの最初のセッションとなった大塚弘記氏の「GitHub実践入門 ─ Pull Requestによる開発の変革」の内容をダイジェストで紹介します。 GitHub実践入門 ─ Pull Requestによる開発の変革 大塚弘記といいます。会社でもリアルでもほとんど@hirocasterと呼ばれています。 今日はメッセージを3つ持ってきました。まず、GitHubを使っている世界と使っていない世界についての話を少し。次に、GitHubを使っているけれど、十分に使っているかどうか、という話をして、最後に

    GitHub実践入門、Pull Requestによる開発の変革。GitHub Kaigi 2014
  • 覚えておきたいDevToolsのコマンドラインAPIまとめ - Qiita

    DevTools、使ってますか? もはやChromeじゃないと開発できないくらいに飼い慣らされています。 ブレークポイントやconsole.logなど基的な使い方から、TimelineとAuditsを使ってのパフォーマンス計測などなど、DevToolsのポテンシャルは計り知れません。 個人的にはConsole APIが好きなんですが、今回はConsoleパネルで使える Command Line API の使い方についてまとめてみました。 $_ $_には最後に評価した式の結果が保存されています。 Console上で計算を行なった場合や、$セレクタなどでDOMを検索した結果など、最後の結果が常に保存されます。 $0 〜 $4 $0から$4にはElementsパネルで選択した要素が5つ保存されています。$0が最後に選択した要素で数字が増えるごとに過去に選択した要素になります。 $0は特に使いや

    覚えておきたいDevToolsのコマンドラインAPIまとめ - Qiita
  • Railsアプリつくった - ✘╹◡╹✘

    最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計

    Railsアプリつくった - ✘╹◡╹✘
    NetPenguin
    NetPenguin 2014/04/08
    これは良い記事。
  • 開発環境の情報共有会でDash,SourceTree,Alfredの話をした - Glide Note

    社内で開発環境についての情報を共有する会を開催した。 参加者全員が発表のスタイルで、ただ聞いてるだけの人がいないようにしたら いろいろな情報を共有出来て大変参考になった。 私は1日のほとんどをターミナル上で過ごすので、ここ数年GUIアプリにはあんまり関心が 無かったんですが、最近導入して便利だったやつを共有したら好評だったのでまとめておく。 Dash Dash - Documentation Browser, Snippet Manager - Kapeli ドキュメントブラウザ、スニペット管理ツール。ドキュメントをローカルにダウンロードして 利用するので高速。今日(2014/03/29)時点で130以上のドキュメントとAPIに対応していて、 プログラミング言語に加えて、MySQL、MongoDB、Puppet、Vagrantなどのドキュメントもある。 自作ドキュメントを追加することも可能

    NetPenguin
    NetPenguin 2014/03/31
    ドキュメントブラウザ、gitクライアント
  • なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;

    最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良いだった。このを読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと

    なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
    NetPenguin
    NetPenguin 2014/03/25
    経験上、一日は6時間のつもりでスケジュール引くのが良さそう。みっちり働いてもそんな感じになる気がする。あと、工数は直感の1.5倍〜2倍ぐらいが妥当な感じ。精度と正確性を分けて考えるほうが良さげ。
  • Etsyはいかにして1日に50回ものデプロイをしているのか

    Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

    Etsyはいかにして1日に50回ものデプロイをしているのか
  • Javaトラブルに応じた初動対応のまとめ - n-agetsumaの日記

    Javaトラブルでは『情報がなくて、再現もなかなかしません』といった状況に陥ることがある。このような状況を回避するために、以下の3つの代表的なトラブルを例に、アプリケーションサーバを再起動する前に何を取得すれば良いのかをまとめてみる。 アプリケーションから応答がない アプリケーションが遅い ヒープメモリが足りない(OutOfMemoryErrorの発生) アプリケーションから応答がない 取得する情報 スレッドダンプ データ取得方法 スレッドダンプとは、コマンド実行時点でのJavaスレッド実行状態を出力したものである。応答がない場合、何らかの要因によりどこかで処理が止まっていることが想定される。スレッドダンプは『どこで止まっているのか?』を切り分けるのに大切な情報である。 取得方法はJDKのバージョンによって色々ある。 kill -3 <pid> (少なくとも1.4.2にはある〜JDK7でも

    Javaトラブルに応じた初動対応のまとめ - n-agetsumaの日記
    NetPenguin
    NetPenguin 2014/03/12
    スレッドダンプの出し方とか。
  • 技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog

    元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニア

    技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
    NetPenguin
    NetPenguin 2014/02/19
    あるわー、わかるわー
  • これからiOSやる奴はここ読んどけ - Qiita

    これからiOSアプリ開発をやりたい!という人へ 自分が実際にiOSアプリ開発をやって、便利だったと思う情報を残しておきます。 これからアプリ開発やりたいという人の参考になれば。 iOSアプリ開発の第一歩 まずは間違いなくMacを買うこと。 Macを書いましょう。Windowsじゃ開発できません。 MacじゃないとiOSアプリの開発はできないので、 これがないとお話になりません。。。 インストールしておくもの 基的にXcodeさえインストールしておけばアプリの開発はできます。 Mac App Storeからダウンロードできます。 実機インストールやApp Storeに公開したい場合は、 iOS Developer Programを購入する必要があります。 まずはこれを読むべき Appleのドキュメント集(日語訳Version) https://developer.apple.com/jp

    これからiOSやる奴はここ読んどけ - Qiita