システムプログラミング会のまとめ* システムプログラミング会 - connpass http://connpass.com/event/34995/ がおもしろそうだったので， #spkai をまとめました． 何かあればお手数をおかけしますが，ご連絡下さい． あるいは，編集できるようにしてあるはずなので，編集して下さい．
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
脱・読みづらいコード！今日から一段上のプログラマーになる方法 5 選 - xin9le.net
「ソースコードを綺麗に書く」というのは、プログラマーであれば誰しもが心掛けたいと思っている極めて重要な事柄です。そもそも「綺麗なコードってなんぞ？」という感じですが、いくつかあると思います。 改行位置/空行の数/インデントなどに一貫性があり整っていて、パッと見が綺麗 「こんな難しいことがこんなに簡単に書けるなんて！」というエレガントさ 理解しやすい etc... ひとつ目は美的感覚の問題なので、基本的には人それぞれということで今回は言及しないことにします。チーム開発の場合はソースコード整形ツールで一定のクオリティを維持するのがお手軽ですね。ふたつ目もさておき、今回は「理解しやすさ」について考えてみようと思います。主にプログラミングの勉強を始めた人向け。 ※ 画像を借りているだけで、この本のオススメをする記事ではありません！ 1. そのコードを誰が読むのかを考える 「理解しやすいコード」は「
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
5 年続く 「はてなブックマーク」 アプリを継続開発する技術
Why and How should you approach to Android Security in architecting phase, implementation phase, and operation phase. This includes what type of secure planning should be considered in term of business domain, what type of universal secure coding should be done. It also talks about how should you store keystores and its password in safe manner.
【機械学習】Yahoo Newsの記事をMLlibのトピックモデル(LDA)でクラスタリングする。 - Qiita
Sparkシリーズ第３弾の記事です。MLlibのLDAを使ってYahoo Newsの記事をトピックモデル(LDA:Latent Dirichlet allocation)でクラスタリングしてみます。 第一弾 【機械学習】iPython NotebookでSparkを起動させてMLlibを試す http://qiita.com/kenmatsu4/items/00ad151e857d546a97c3 第二弾 【機械学習】Spark MLlibをPythonで動かしてレコメンデーションしてみる http://qiita.com/kenmatsu4/items/42fa2f17865f7914688d 0. 環境 OS: Mac OSX Yosemite 10.10.3 Spark: spark-1.5.0-bin-hadoop2.6 Python: 2.7.10 |Anaconda 2.2.0
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
Android開発いろいろ
eventbus.md EventBus EventBus は必ず onStart() と onStop() で呼ぶ。バックグラウンドで色々動かれて困る。 また、onStop() では super.onStop() よりも 先に 呼ぶ。 @Override protected void onStart() { super.onStart(); EventBus.getDefault().register(this); } @Override protected void onStop() { EventBus.getDefault().unregister(this); } proguard の設定 忘れがちですが、設定しないと最適化オプション付けたときに死ぬ -keepclassmembers class ** { public void onEvent*(**); } # Only r
コンパイラ - コンパイラの最適化についてすべてのプログラマが知っておくべきこと
注意 このページにアクセスするには、承認が必要です。 サインインまたはディレクトリの変更を試すことができます。 このページにアクセスするには、承認が必要です。 ディレクトリの変更を試すことができます。 コンパイラの最適化についてすべてのプログラマが知っておくべきこと Hadi Brais コード サンプルのダウンロード 高度なプログラミング言語には、関数、条件付きステートメント、ループなど、驚くほど生産性が上る抽象プログラミング コンストラクトが多数用意されています。ただし、高度なプログラミング言語でコードを作成する場合のデメリットの 1 つは、パフォーマンスが大幅に低下するおそれがあることです。パフォーマンスを犠牲にすることなく、わかりやすく、メンテナンスしやすいコードを作成するのが理想です。このため、コンパイラがコードを自動的に最適化してパフォーマンスの向上を図ります。最近のコンパイラ
Androidアプリ開発を独学で学ぶ人への効果的な勉強法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事では、Android開発を始める方や、初めたての方向けにどのようなサイトを見たり、本を読んだらいいかをレベル別や用途別で解説します。 本の紹介などはすでに多く存在しますが、使いどころというのは本によって大きく違います。この記事ではその使いどころに意識してソースを紹介できればと思います。 また、Androidプログラミング初心者とプログラミング初心者は区別しません（合わせて"プログラミング初心者"と記述）。Androidのアプリ開発はベースとなっているJava言語が直感的に理解しやすいこともあり、他のプログラミング言語を習得してい
メソッド名をシンプルにするために、 知っておくと便利な英語のprefixとsuffix - codic ブログ
メソッド名などをネーミングする際に、知っておくと便利な、接頭辞と接尾辞をリストアップしてみました。どのように元の単語の意味が変わるかのルールを知っておくと、よく使う単語をベースにボキャブラリーを増やすことができるので、覚えておいて損はないと思います。 使う場合は、当たりを付けて実際の使用がないか、Googleなどで調べてみてください。 1. pre-, post- / 事前〜、事後〜 per-は、元の意味に “事前に、前に”、post-は “事後に”という意味が付け加わえます。汎用性が高いのでとても便利です。afterやbeforeの代替になるかもしれません。 // 事前テストする function testBefore(); ↓ function pretest(); // 事後処理する function executeAfter(); ↓ function postexecute();
開発効率アンチパターン
Oculus Rift 勉強会 関西 #02 【OcuBen関西】 https://ocuben.doorkeeper.jp/events/31601 『Oculus Rift入門』で使用した資料です Oculus Rift勉強会 関西 #01 【OcuBen関西】 https://ocuben.doorkeeper.jp/events/21033 『スマホでVRコンテンツを作る！！！』の発表に使用した資料です。 多少修正していますが、発表に使った資料をほぼそのままです。 【2015/3/29 資料更新】 ①タオバイザーがAmazonで購入可能なことを記載しました。 ②Cardboard SDKがUnity 5に対応したことを記載しました。 Durovis Diveを使用したVRスマホアプリの作り方について解説しています。 #OcuBen 関西に合わせて2つのAndroidアプリをPlay
マジックビーンズ
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
Bayonetta2 開発ブログ - Wii U専用ソフト『Bayonetta 2』（ベヨネッタ2）に関する情報を、開発者みずからお届けするブログです。Bayonetta2 開発ブログ
Bayonetta2 開発ブログ 『ベヨネッタ２』発売２周年＆amiibo初公開！ 2016.09.20
バグの間抜けな倒しかた - kuenishi's blog
プログラムを書いていると、間抜けなバグをいくらでも仕込むことができる。たとえば一文字だけのTypoだったり、ifの括弧のつけわすれであったり、エラー処理をひとつ忘れていたり、もしくはその言語特有の間抜けなバグというものもあるだろう。そういったバグは往々にしてコードレビューはテストを掻い潜ってしまう。製品や本番のコードに残ったままリリースされ、とてもヘンなデータが入ったり障害が起きたりしたときにだけ発露する。今回のはなしもそのエラー処理をひとつ忘れてリリースしてしまったことがきっかけではあるのだが、むしろバグの見つけ方が間抜けであったことをここに書いて今後の反省の材料としたい。 riak_cs#985 はそんなバグのひとつで、エラー処理をひとつ忘れて Riak CS のコネクションプールが漏れていたという話だ。再現条件としては、ユーザに関するAPI（一覧GETなど）を叩いたり、 Author
これからAndroidの開発を始める人がお世話になるだろうサイト一覧 - genonymous
こんにちは、釘宮です。 新しい言語の開発を始めたとき、検索という行為が結構大きな時間を食ってしまうものです。 その検索を効率的にするのに有効な手段として、熟知している人の情報源を知る事が一つだと思います。 ということで今回、Android開発歴3,4年の私、釘宮の情報源を少数精鋭で紹介したいと思います！ 言わずもがな ○ Android Developers まずはAndroidの公式デベロッパーサイト。 関数の仕様などリファレンス一覧以外にもDesignなどでGoogleのすすめるこれからのAndroidの標準デザインなどは必読です。 ３種の神器 ○ Stack Overflow このサイトなしでプログラムをくみ上げることができるのか？いや、むりだろう。 という方も多いのではないでしょうか？ 幾度となく我々プログラマを救ってくれたStackOverflowさんはAndroidも十二分
リーダブル・コードを書く | POSTD
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself（DRY）に従えば、バグも
「失敗を活かす」を実現する仕組みづくり - ワザノバ | wazanova
http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem（個人批判をしない建設的な障害の振返りミーティング）というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
コードレビューのススメ
