werckerからGAE/Goにデプロイするスクリプトを作ったものの既に作り直したいなと思っている話 - けいまさんですけど
はじめに DroidKaigiお疲れ様でした（雑感ブログはまた今度書くかもしれないし、書かないかも知れません） DroidKaigiの準備が忙しくなってきた年明けすぐ頃にぼんやりと考えていたことを、DroidKaigiが無事に終わったのを契機に本格的に作り始め、なんとか動くようになったのでご紹介したいと思います。 GAE/Goと僕 僕は趣味で作るWebアプリはだいたいGAE/Goで制作をしています。 GAE/Goを選ぶ理由としては、個人用途ではほぼ無課金で遊べること、そしてGo言語を動かせるプラットフォームとしてはかなりお手軽な部類であることが挙げられます。 （go1.5対応はスルーされたけど）go1.6対応はされるということで、まだアクティブにプラットフォーム開発が続けられていることも好印象です。 Bitbucketとwercker werckerというCIサービスがあります。 パブリッ
goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話 - Qiita
by @mixiappwchr おしゃべりマルチとは 今回UUUM株式会社様からアプリ開発の受託をうけ おしゃべりマルチ という音声チャットをやりながら、マインクラフトPE など、ゲームのマルチプレイができるというアプリをリリースさせていただきました。 マインクラフトだけではなく、モンストや、白猫プロジェクト、その他マルチゲームで使ってもらえると楽しいアプリとなっています。 主な設計 今回 複数のサーバーをくみあわせて、音声チャットマルチプレイを実現しています。 ３つのサーバーとアプリが連携 APIサーバー 音声サーバー マイクラプロキシ兼リアルタイムイベントサーバー の３つが協調して動きアプリにサービスを提供します。 本来マイクラマルチは同一内WiFIだと気軽にできるのですが、インターネット越しとなると、ルーターのポートを解放したり、なんだかんだ面倒な点が多いのですが、このアプリをいれる
Go本体にContribute成功した話 と Gerritの話 - stanaka's blog
来月ぐらいにはGo 1.7がリリースされそうなのですが、CONTRIBUTORSに名前が載せられそう( https://github.com/golang/go/blob/release-branch.go1.7/CONTRIBUTORS#L915 )なので記念エントリです。 内容自体は、4月にあったGoCon 2016 Spring( http://gocon.connpass.com/event/27521/ )での発表済みです。 tl;dr 一部のディストリの最新版でlinux/386でビルドしたバイナリが起動すらできない、というバグがあった 問題はruntimeのアセンブラ部分だったけど、なんとかパッチ書けた パッチ提出→コードレビュー→やりとり→マージまで、3日程度とスムーズに進行できた https://go-review.googlesource.com/#/c/21190/
Composerを速くするために必要だったもの // Speaker Deck
PHPカンファレンス関西2016の基調講演です。
海外エンジニアが話題にしていて「なるほど」と思ったプログラミングに関する考え方３つ - ジンジャー研究室
プログラミングに関する格言みたいなのは昔から結構あって、例えばYAGNIみたいに日本でも十分浸透してるのは多いんだけど、やっぱり新しい概念はどんどん生まれていくので追いかけていると面白い。 というわけで、最近知った中でもっと日本でも言及されても良いと思ったやつを３つ紹介。 Simple Made Easy Rich Hickey（Clojure言語の作者）による講演(2011年)のタイトル。全文はここで読める。英語しんどくてPOSTDに投げたんだけど音沙汰がない。まだ全部見てないから和訳欲しい。 内容としては、みんな安易に「簡単」なものを選びがちだけど「シンプル」なものの方が価値あるぜ、というもの。曰く、「シンプル」は絶対的・客観的な指標だけど「簡単」は相対的・主観的なもの。例えば英語の話者にとってドイツ語は難しいが、それは自分にとって「遠い」存在であるだけで悪いものじゃない。 「慣れてい
JavaScript開発における多段式エラープルーフについて - 若くない何かの悩み
第14回HTML5ビギナーズで、JavaScript のデバッグ作業を短くする「多段式エラープルーフ」について発表してきました。 スライド speakerdeck.com コードのサンプル github.com まとめ JavaScript のデバッグ作業を素早くこなすなら、多段式エラープルーフが必要です。
Rails アプリケーションにおけるリファクタリングの実践 - peroli Developer's Blog
2016 - 05 - 06 Rails アプリケーションにおけるリファクタリングの実践 Ruby on Rails こんにちは、MERY のサーバサイド開発をしている末並 @a_suenami です。 TDD、 アジャイル 、DB 界隈等によく出没しますが、最近では糖質警察としてのほうが広く知られている気がする今日この頃です。糖質制限に興味ある方はぜひウィスキーを片手にケトン体の話でもしながら飲みましょう。 さて、現在、MERY は Ruby on Rails で開発されていますが、最初にリリースされたのはもう 3 年近く前であり、その頃とはサービスを取り巻く状況が大きく変わってきています。これまで多くのユーザの「かわいい」を支え、よい体験を提供し続けてきた現在の MERY とそのコードベースを否定することは決してできませんが、日々変わるユーザの「かわいい」ニーズと我々のビジネス状況の変
pelletkachels | blog over bedrijven en feitjes en de pelletkachel
Welkom bij Pelletkachels.nl, jouw ultieme bron voor alles wat met pelletkachels te maken heeft! Maar we zijn meer dan alleen een platform voor het bespreken van warmtebronnen. Bij Pelletkachels.nl geloven we dat het delen van kennis en ervaringen over bedrijven en gebeurtenissen ook essentieel is voor het creëren van een betrokken en geïnformeerde gemeenschap. In dit blog duiken we dieper in de we
Landscape.io Blog
It has been more than seven years now since I started making Landscape: Author: carlio <git@carlcrowder.com> Date: Wed Jan 30 08:42:29 2013 +0100 Initial commit What started as scratching my own itch - I wanted something like SonarQube but for Python. I really worked hard to make … more ... Now that 2016 has shuffled off this mortal coil and we can all take a breather and see what 2017 brings us,
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
現場のフォーム - steps to phantasien
このごろ仕事の進みが悪く、しかもまったくの自業自得で肩を落としている。 今日はそれをふりかえり明日への糧としたい。反省文。 仕事の進みは「遅い」だけ。動いてはいる。一歩一歩は正しい。 でも一歩を踏み出すまでが遅い。正しい一歩を踏み出せる、正しい姿勢をとるのが遅い。 背中を丸め足を引きずる。たとえばこんなふうに… Bisection ある昼下がりにバグ修正を頼まれた。リグレッション。ここ三ヶ月くらいで壊れたらしい。 リグレッションを直す「正しい」一歩目は、二分探索で原因のリビジョンを探す bisection 作業だ。 でもこのバグ、bisection が面倒そう。なんとなく原因の想像はつくからあたりをつけて直してしまおう・・・ ・・・半日たち、結局あたりはつかない。日が暮れてしょんぼり帰宅。 翌朝気を取り直し bisection をしたら 2 時間でリビジョンの特定がおわる。あらら。 しかも
mrubyを小さくしたり大きくしたりした話 - スペクトラム
最近mrubyにコミットしているので自分の活動をまとめます。 mrubyを小さくした話 mrubyでは、文字列の扱いはシンプルにchar*を構造体でラップしていました。 struct RString { MRB_OBJECT_HEADER; mrb_int len; union { mrb_int capa; struct mrb_shared_string *shared; } aux; char *ptr; }; そのため1つの文字列毎に、構造体分と文字列分の2回のmalloc/freeが発生していました。 ここでCRubyのRStringを見てみます。 #define RSTRING_EMBED_LEN_MAX ((int)((sizeof(VALUE)*3)/sizeof(char)-1)) struct RString { struct RBasic basic; union {
初心者のうちから循環的複雑度を意識すれば立派なプログラマーになれる : IT速報
729:仕様書無しさん 2013/05/29(水) 09:05:13.38 コードの品質なら、循環的複雑度を調べればだいたい分かる。 多分殆どの言語で調べるツールが存在する。 ソースコード指定して実行するだけ。 循環的複雑度も正しいと言い切れないところはあるし 不正に複雑度を下げることもできるが、 まあ、循環的複雑度を知らないようなところは どうせソースコードは汚い。 732:仕様書無しさん 2013/05/29(水) 12:10:00.09 >>729 複雑度は品質の指標ではなくテスト容易性の指標。 735:仕様書無しさん 2013/05/29(水) 17:56:56.38 >>732 循環的複雑度は、ソフトウェアの品質を測る為のメトリクスの一つで、ある程度の指標にはなると思う。 複雑だから駄目、簡単だから良いというようなことではないけど。 循環的複雑度は、ISO9126で定義される、
コードの互換性と進化の両立
Jenkinsでつちかった、コードの互換性を保ちつつ様々な修正を加えていく技法を紹介します。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tmrts/boilr: :zap: boilerplate template manager that generates files or directories from template repositories
10年を超えるレガシーwebサービスの重複ライブラリを削除してコード量を2:3にした話
Strict mode · Issue #1659 · emscripten-core/emscripten
GitHub - mizzy/serverspec: RSpec tests for your servers configured by CFEngine, Puppet, Chef, Ansible, Itamae or anything else even by hand
GitHub - gregorym/bump: Bump is a gem that will simplify the way you build gems.
Package managers
