ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiAより速く より運用しやすく 進化し続けるJVM（Java Developers Summit Online 2023 発表資料）
gitの入門用のチュートリアル"Learn Git Branching"を訳した | 48JIGEN *Reloaded*
gitの入門用のチュートリアル"Learn Git Branching"を訳した 2013/03/18 ここで公開してます。スマホからだと動かないのでPCで見てください。 http://remore.github.com/learnGitBranching-ja ChromeとFirefoxでは動作確認してます。翻訳リソースはgithubに置いてあります。 Laern Git Branchingは： グラフィカルにgitツリーを操作しながらrebaseとかmergeとかを学べる IDEA * IDEAさんとかHackerNewsとかで、1か月くらい前に話題になってた MIT Lisenceで公開されてて自分で演習問題も作れる というツール。公開されてから1か月くらいしか経ってないのに、既に中国語、韓国語、フランス語の3か国語に翻訳されてる。海外の人仕事はえーと感心しました。 春だし新人さん
Ruby には Perl の Plagger のようなお手本はないの？ - gan2 の Ruby 勉強日記
その中でも直近の大規模なオープンソースプロダクトである Plagger はまさに Perl Hacker の教科書とも言えるべき存在だ。 http://d.hatena.ne.jp/tokuhirom/20080719/1216423454 ということで、Perl では「Plagger」が お手本となるソースとしてお勧めされているようなのだけど、 Ruby には Plagger のようなお手本となるソースはないのだろうか？ 先日行われた Yugui さんと角谷さんのトークセッションでは BitClustなどの青木さんが最近書かれたライブラリのソースがお勧めされていた模様。 青木さんの書かれたライブラリはLoveRubyNetに一覧がある。 でもこのトークセッションでは「Perl の Plagger にあたるものが Ruby にはない」とも言われていたそう。 そういえば前に id:rubik
続・技術的負債の把握と改善を促すために - mixi engineer blog
こんにちは, 先日Kansai.pmで発表させて頂いたgoccyこと五嶋＠たんぽぽグループです. 今回は, 前回紹介した技術的負債の把握と改善を促すためにの続編として, 僕が作ったPerl5コードのコピペ検出器について紹介させて頂きます. はじめに 今やPerl, Ruby等さまざまな言語で, 便利なライブラリ群やフレームワークを利用できる時代になりました. これらを使うことでソフトウェアの開発コストは格段に下がり, より素早く開発することができるようになっています. しかし, 当初予定されていた機能を実装して, 「よしできたから終わり！」というわけにもいきません. 何か物を生み出せば, 必ずそれを保守・運用するコストが発生します. 開発することが便利になった今, 開発物を保守・運用することを支援するツールも求められています. ですが, 保守や運用, とりわけ保守に関して支援するツールはそ
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～ Presentation Transcript DevelopersSummit 自動改札機の 運賃計算プログラムのデバッグ手法 ～1040のパターンをいかにテストするか～14-B-3 幡山 五郎#devsumiB オムロンソーシアルソリューションズ ソリューション事業本部 Developers Summit 2013 Action ! １．自動改札機について 1. 自動改札機について 2. 間違えない自動改札機 2 １．自動改札機について自動改札機導入前の改札風景 3 １．自動改札機について磁気からＩＣへ求められる技術が変わってきた（高機能化→高信頼化） 2013年 ＩＣ乗車券全国共通化（北海道～九州の10種類） 2007年 ＰＡＳＭＯ導入、Suica+PASMO
naoyaのはてなダイアリー - Perl のクロージャ
いつもお世話になってるあの人とかあの人とかが山口家の逆襲->perl-解説->クロージャというクロージャの解説ページをブックマークしてるのをきっかけに、 Perl のクロージャについて自分もちゃんと理解できてるのかというのを考えてみましたが、どうも微妙です。 クロージャについて、何でいまいち理解しきれてない感じがあるのかというと、クロージャがどういうものであるかは知ってるけど、クロージャをどういう時に使うと良いのかが具体的にあれとこれという感じで思い付かないからなのではないかと思った。 なので、Perl でクロージャを使ってる実装とかを見て、どんなときに使われるものなのかをリストアップして理解を深めてみよう..のコーナーです。 クラスにデータを保持するためのクロージャ 僕がぱっと思いついたのは Class::DBI の中で使われている Ima::DBI におけるデータベースハンドラのキャッ
ペアプログラミングをしていたら、開発環境が良くなった話 - $shibayu36->blog;
最近、仕事で一週間に一度はペアプロをするということをしているのですが、これによって思ってもみなかった効果が出たので紹介します。 ペアプロというとプログラムを書いている人の後ろでもう一人が見ていて、逐次指摘などしながらプログラミングすることによって、生産性の向上やバグ発生率を抑えるみたいなことが言われています。僕自身もそう思いながらペアプロに望んでいたのですが、違うところで効果が出始めました。それは自身の開発環境がだんだん良くなっているということです。 ペアプロによって開発環境が良くなる 今回開発環境といっているのは、emacsなどのエディタや、ターミナルなど、ローカルマシンの設定などのことです。 なぜ開発環境がよくなっていっているというと、見ている時と見られている時のそれぞれにおいて、次のようなことが起こるからです。 見ている時 後ろから見ていると突然プログラムを書いている人が、自分の知ら
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
Androidの機種依存問題を吸収するプロジェクトAndroid-Device-Compatibilityを公開したお話 - mixi engineer blog
こんにちは。Androidユニットで開発とスクラムマスターをしています、横幕です。すっかり寒くなって、朝起きるのが辛い季節になりました。 先日、Android(TM)の様々な機種に依存する問題を吸収するためのライブラリプロジェクトをmixi, IncのGitHubリポジトリで公開しました。 今回は、このライブラリプロジェクトを公開するに至った経緯をお話しようと思います。 様々な種類の端末に対応するために乗り越えてきた困難 現在、Androidを搭載した端末には、多種多様なものがあります。 そして、OSのバージョンごとの違いだけでなく、同じAndroidを搭載していても、端末ごとに微妙に挙動が異なることがあります。 mixi公式クライアントアプリでも、端末ごとに微妙に挙動が異なることで発生する問題にいくつか直面してきました。 特定の端末で、文字が9,000文字までしか入力できない EditT
ド素人が完全自作SNSを二週間運営してみてわかったこと（後始末編、技術編、モチベーション編）
ド素人が完全自作SNSを作ってみてわかったこと。 http://anond.hatelabo.jp/20130104184115 の元増田です。 ひっそりと公開したはずのtag-chat.net(http://tag-chat.net)ですが、 まさか、こんなに反響を頂けるとは思っていなかったので、びっくりしました。 素人のフリをしているとか、出版社のステマだとか色々言われましたが、嘘は一切書いてないです。 ステマというか、ウェブサービス公開後の状況を知っている方からするとマイナスのステマにしかなっていないような気がします…。 公開してから、色々と発見というか気づきがあったので、それを共有できれば幸いです。あと、tag-chat.netの中身についてなど。 ～増田記事を公開してから今までの経過～ ・意気揚々と自作SNSを公開したものの、アクセスが全くこなくて途方にくれる。 ⇓ ・以前、完全
「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演させていただきました #TddAdventJp #devlove2012 - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar jp: 2012 の 17 日目の参加エントリです。前日のエントリは [twitter:@shuji_w6e] さんの「軽量なテスト駆動開発を目指して」でした。 久しぶりのエントリです。久しぶりどころか、なんと日記の更新が一年ぶりになってしまいました……(もはや年記ですね)。 昨日、二日間開催された DevLOVE 2012 の二日目最後の(?)講演として、「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演をさせて頂きました。 DevLOVE では何度か登壇の機会を頂いているのですが、昨日はいつもとは少しだけ違いました。その違いとは「イベントで私以外にも TDD の事を講演する人が複数いる」ということでした。諸橋さん([twitter:@moro])の「テストに開発をもっと駆動させたい」と和智さん
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
第8回 Perlによる大規模システム開発・設計のツボ（1） | gihyo.jp
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはmixiの広木大地さんで、テーマは「大規模システム開発・設計のツボ」です。 仕事やOSS（Open Source Software）プロジェクトでPerlを用いた多人数開発をするにあたって気をつけるべきことや、品質を維持するためのノウハウを、国内最大級のPerlシステムであるmixiの事例をベースに紹介します。コーディング上の命名に関する考え方から、大規模アーキテクチャの設計や品質の数値化まで、ミクロからマクロに至るポリシーやテクニックを駆け足で解説します。 なお、今回の内容は（株）ミクシィの2010年度の新卒エンジニア技術教育メニューからの抜粋になります。これからPerl をはじめとするLL（Lightweight Language、軽量言語）を仕事で使うというフレッシュエンジニアのみなさんにも、ぜひご一
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
レガシーPHP改善日記 シーズン1 エピソード2 - komagataのブログ
hrysd心を折られるチンカスプログラマーことhrysdがバイトで来てくれることになったので一緒に大門に出社。 初出社前に既にバグを一個潰してコミットしているという荒業を見せたhrysdだが、3000行を超えるcontrollerに早くも心を折られる。 俺「actionのメソッドが5行を超えたら危険印、なんていうrailsのぬるま湯に使ってたんだよ！これがサバンナだ。」 Github Organization契約出社後早速、社長にGithub Organization Bronzeプランを契約してもらう。技術的なことはわからないというが、リスクを背負って立てなおそうという気持ちが伝わって来ました。 9月30日の直近の締め切りに間に合わないのでsvn + redmineからの移行は10月にお預けだ。 svnがよくわかってないまずはsvnでもトップにぶち撒けられてるというのは辛いのでtrunk
[iOS5] ARC : プロパティ属性と使い方 | Natsu note
strong __strong修飾子に対応するプロパティ属性です。strong属性を用いたプロパティは参照先オブジェクトのオーナーとなります。 weak __weak修飾子に対応するプロパティ属性です。__weak修飾子を持った変数と同様、weak属性のプロパティも、参照先のオブジェクトが破棄されたら自動的にnilが代入されます。weak属性を用いたプロパティはオーナーシップ権を持ちません。 weak属性は、delegateやOutletの変数に最適です。 なお、iOS 4では__weak修飾子が使えないため、プロパティのweak属性も使えません。この場合は、後述のunsafe_unretainedを使いましょう。 copy __strong修飾子に対応しますが、実際にはコピーオブジェクトが代入されます。copy属性を用いたプロパティは参照先オブジェクトのオーナーとなります。 unsafe
イマドキっ子の Objective-C
イマドキの流行に敏感なキミだったらもう知ってるかもだけど、今日はそういうのに鈍感なオジサンたちのために、今風の Objective-C について書いちゃうよ。もちろん互換性的な感じで、すぐに変えられないかもってコもいると思うけど、知っててもソンじゃないから、いま覚えとこう！それとこういうのって、けっこー変わっていくものだから、半年後とかにはもう流行後れになるから注意してね！ インスタンス変数 Objective-C のインスタンス変数と言えば、ヘッダの @interface に書くというのがこれまでのルールでした。典型的な例として、以下のように書いていました。 @interface MyObject : NSObject { NSString *aString; } ... @end 今風には、インスタンス変数の宣言は実装部の @implementation に書きます。 @impleme
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
職人が教える！iOSアプリ開発で使いこなしたいとっておきのOSS 記事一覧 | gihyo.jp
GitHubがCSSのパフォーマンス改善のためにおこなったことをまとめたスライド | コリス
iOS Developer Library