開発者のタスク管理をGitHubで行ったらうまくいった話 | DevelopersIO
はじめに こんにちは、6月からAndroidの開発を担当している荒川です。 この記事は以下の方を対象にしています。 リモートリポジトリにGitHubを使っている タスクや課題の管理を小〜中規模のプロジェクトで行っている 複数の開発タスクが並行して進むプロジェクトにアサインされている 開発者のみのタスク管理を主体的に行いたい タスク管理ツールを使っているがイマイチうまくいっていない この記事では、私が実践して良かった経験則を紹介します。誰でも真似すれば必ずうまく行くという保証はありません。この記事の読者の方が、担当しているプロジェクトに合わせてアレンジを加えるとより効果が増すかと思います。 開発者のタスク管理 モバイルアプリサービス部では、コミュニケーションツールにBacklogやTrello、Pivotal Trackerを用いている事を突撃！隣の開発環境 パート3【クラスメソッド編】の記
最強のSSH踏み台設定 - Qiita
追記：openssh-7.3 以降なら ProxyJump や -J が使えます ホスト名を + で繋げることで多段Proxy接続も簡単に、がコンセプトだった本エントリの設定ですが、OpenSSH 7.3 から ProxyJump という設定が使えるようになったので、使えるなら ProxyJump を使う方が健全だし柔軟で使い勝手も良いのでそちらを覚えて帰ることをオススメします。 使い方は簡単で以下のような感じです。多段も行けるし、踏み台ホスト毎にユーザ名やポート番号を変えることも出来ます。 # 1. bastion.example.jp -> internal.example.jp ssh -J bastion.example.jp internal.example.jp # 2. bastion.example.jp -> internal.example.jp -> super-de
Redis作者自身によるRedisとMemcachedの比較 | Yakst
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
Import.io
Specialized Web Data ExtractionExtracting protected, high value web data is hard and only getting harder. Import delivers the data that others can't get to. Get a demo
【インターンの新しいカタチ。リモートワークで50人のインターンと共同開発】前編～ 合同会社フィヨルド | リモートワークラボ
社員２人でどこまで出来るか挑戦してみたい 今日は宜しくお願いします。まずは会社の紹介をお願いします。 町田はい。合同会社フィヨルドと言いまして、エンジニアとデザイナーの２人だけの会社です。僕がデザイナーをやっている町田で、もう１人の社員の駒形がエンジニアをやっています。 もともと会社をつくるときに、社員は増やさないと決めたんです。なぜかと言うと、「２人でどこまで出来るか挑戦してみたい」というのが、会社のコンセプトにあったからです。そこはちょっと変わっている点ですね。２人だけの会社で、普段は受託開発を請け負いながら、自社サービスを作っています。 50人のインターンが入れるオフィスを用意するのはもったいない フィヨルドさんのリモートワークについてお聞きしたいんですが、町田さんと駒形さんのお二人も、いつもリモートでお仕事をされているんですか？ 町田私たち二人は割とオフィスに来ていることが多いです
Sidekiq について基本と1年半運用してのあれこれ - まっしろけっけ
はじめに 実際に運用していた時に非同期にしていた主な処理は下記のようなものがあります。 iOS Android の push 通知の送信処理 ログの作成 様々な外部 API の呼び出し 非同期で更新しても問題ないデータの更新 Sidekiq is なに sidekiqは非同期処理を実現する gem 他にも Ruby で非同期処理を実現できる有名な gem には resque や delayed_job 等がある。 sidekiq.org Enterprise版等もありますが、 今回はOSS版を使用している前提でのお話しです。 他の非同期処理が可能な gem との簡単な比較 FAQ · mperham/sidekiq Wiki · GitHub この内容は結構真実を語っていることを最近知った Sidekiq Redis マルチスレッド リトライ処理あり おしゃれなダッシュボード Resque
The New Science of Building Great Teams
If you were looking for teams to rig for success, a call center would be a good place to start. The skills required for call center work are easy to identify and hire for. The tasks involved are clear-cut and easy to monitor. Just about every aspect of team performance is easy to measure: number of issues resolved, customer satisfaction, average handling time (AHT, the golden standard of call cent
npm で依存もタスクも一元化する - Qiita
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
継続的 bundle update サービス deppbot を使ってみた
昨日話題になっていた https://www.deppbot.com と、 拙作のツール ci-build-trigger [2015-07-28-1] を比較してみました。 タイミングよく、Gem のアップデートがあってよかったです。 私のツールが作った Pull request# https://github.com/masutaka/masutaka-metrics/pull/19 deppbot が作った Pull request# https://github.com/masutaka/masutaka-metrics/pull/20 良くなったこと# アップデートされた Gem の情報が Pull request の description にまとまってすっきりした compare_linker では取得できないことがあった、リポジトリや Diff へのリンクが完璧に取得できて
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
【後編】華麗なるキャリアの道程は、『ドワンゴ』から逃げ出したい一心から！？
＜中編のあらすじと後編のお話＞ 広尾の寿司屋で繰り広げられてきた、伊藤直也氏（以下「naoya」）と『株式会社ドワンゴ』の川上量生氏（以下「川上」）の対談もいよいよ後編に突入。川上氏が考えるモノづくりの本質の話から、後編では『ドワンゴ』の職場環境や制度の話、川上氏の論理的思考がいかにして生まれたか、といった話まで広がりをみせます。人として、エンジニアとして成長するためにはどうすればよいか？ その答えとは―― ⇒【中編】の記事はこちら — naoya：川上さんって、CTO就任以降、エンジニアにとって居やすい職場にしたい、なんてことも発言されていますよね？ — 川上：別段なにもしてないですけどね。さっきも言ったように、引っ越しして、インフラ側にエンジニアをコンバートさせたくらいです。 — naoya：あら、そうですか。そのなにもしない感というか、権限委譲するところが居心地の良さに繋がっていたり
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ
YAPC::Asia Tokyo 2015 前夜祭に参加して、柴田さん（ hsbt さん）とモリスさん*1（ tagomoris さん）の講演を聴いた。特に最後のモリスさんの講演を聴いていて、ちょっとした衝撃を受けると共に、気づきや疑問もあったので、久しぶりに blog エントリを書こうという気になった。 なお、このエントリは講演メモや浮かんだ疑問、その後の議論等を記したものであり、すっきりとした結論は無いのでご注意。 モリスさんの講演 講演資料が公開されていた How to create/improve OSS products and its community from SATOSHI TAGOMORI 講演時に取ったメモがこちら 我々にできるOSSとそのコミュニティの育てかた ======================= id:tagomoris TD のモリスさん TD はデー
GitHub経由で海外から仕事が来た話 - その後のその後
はじめて海外から（フリーランスとして）仕事をいただく、という貴重な経験ができたので、その経緯などを書いてみたいと思います。 きっかけ 7月末のある日、知らないメールアドレスから英語のメールが来ました。内容を一部だけ抜粋すると、 We are looking for someone to develop a very simple apple watch app and a companion apple phone app. というわけで、Apple Watch アプリをつくって欲しい、とのこと。内容を読むと加速度センサとジャイロを使いたいそうで、必然的に watchOS 2 案件になりそうです。 メールには明記されてませんでしたが、GitHub で公開している watchOS-2-Sampler を見て連絡くれたのかなと。（※もちろん面識はなく、共通の知り合いもいないので、これ以外にわざ
Ruby/Railsで文字コードの変換（エンコード）とエンコーディングの確認方法のまとめ - Rails Webook
Ruby/Railsで文字コードの変換（エンコード）とエンコーディングの確認方法をまとめました。 Ruby標準で、下記のような文字コードを変換、確認するライブラリがあるのですが、どれを使ったらわからないのでまとめてみました。 ちなみに、Ruby 2.0からはutf-8がデフォルトのコードです。 Rubyで文字コードの変換 String型のencodeメソッド => Encoding::UndefinedConversationErrorrが発生する、オプションで防げる KConvのto*やkconvメソッド => 基本的には問題無いが、半角が全角になる（MIMEがデコードされる？） NKFのnkfメソッド => 基本的には問題無い。半角も半角のままできる（MIMEも）。KConvは内部的にNKFを使っている。 Iconv (未調査) Uconv (未調査) => Ruby標準ではないっぽい
1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
起業するのはカンタンだけど“会社っぽくする”ことが、難しい
僕が「起業で大事なこと」を挙げるとしたら、以下の3つです。 ・3人で起業すること ・代表は1人に絞ること ・「集まれる場所」を確保すること まず1つ目。なぜ「3人で起業すること」が大事なのかというと、1人だけでは会社がスケールしにくいからです。チームで起業をしないとなかなか会社を大きくすることはできないのではないかと思っています。 そもそも会社とは、人数を増やしていくことがとても難しいものです。1人からスタートすると、リソースが少ないため、事業を作りづらく、さらに創業者1人の期間が長い会社は、周囲から「入りづらい」と感じられてしまいます。 会社を成長させる、また、新しく入社する人が入りやすくするためにも「3人で起業する」ことをおすすめしています。 もちろん、「2人で起業する」のもいいですが、2人はチームとは言えないのです。音楽にたとえて言うと、B’zが「バンド」とは呼ばれないように、やはり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Elegantt