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
疎結合っていいよね - wyukawa's diary
今までの経験でいろんなレイヤーで依存性べったりで密結合なシステムを見てきてそれをちょっとだけ改善してきて思うところを書いてみる。 小さなシステムであれば多少は密結合でも何とかなるかもしれない、というか扱うファイル数、Gitプロジェクト数が1つでむしろやりやすいかもしれないけどシステムが大きくなるにだんだん拡張しにくくなる。かといって最初からあまりにも小さなシステムに分割するとそれはそれでやりづらい。完璧な答えは無いけれど僕が見てきたシステムの話をしよう。 その前にまず依存性といってもいろんなレイヤーがあると思うので、ここでは以下の３つの話をしよう。 アプリケーション内のコンポーネント間の依存性 システム間の依存性 バッチ内の各ジョブ間の依存性 1番目のアプリケーション内のコンポーネント間の依存性の例をあげるとMVCである。 SpringでWebアプリケーションを組んだ場合にModelがあっ
今どきのPythonのライブラリ自作からPyPIへの登録 - Qiita
自分のライブラリをPyPIに登録したい ...が、PythonにはRubyのbundlerのようなものが なく、(合ったとしても統一されてないと思う) プロダクト別に自由なディレクトリ構成になっている状態... せめて自分のプロダクトについては統一したいなあと思ったので Pythonのライブラリを作る場合のディレクトリ構成や 環境構築などについてメモを書く。忘れちゃうので... 利用するPythonのバージョンは3.3以降を意識してる。 それより前(3.2, 3.1...2.x)は考慮しない。問題無いと思うけど... テスト目的で作成したライブラリ fizzbuzzというアレなライブラリを作った。 ライブラリというかコマンドラインツールだけれど。 このライブラリの構成を元に、メモを書いていく。 ライブラリのディレクトリ・ファイル構成 以下のディレクトリ・ファイル構成とする。 fizzbuz
go言語のテスティングフレームワークについて — さにあらず
長いので結論だけ先に。 BDD風味に違和感が無いなら、Ginkgoがオススメ。 もっと軽くてシンプルなのが良いなら、Testifyがオススメ。 テスト対象となるコード 公式のHow to Write Go CodeからYour first libraryにあるコードを持ってきます。 package go_testing // Sqrt returns an approximation to the square root of x. func Sqrt(x float64) float64 { z := 1.0 for i := 0; i < 1000; i++ { z -= (z*z - x) / (2 * z) } return z } 標準で組込まれているテスト用ライブラリについて testing.* 実用性は確かにあって必要なものは揃ってる感あるのだけど、僕にはいくばくかの辛みがあ
実行中のアプリケーションを外から観察するコマンド。 - こせきの技術日記
strace システムコールをトレース。カーネルと何を話しているか。 strace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 straceを使ったデバッグ - SourceForge.JP Magazine : オープンソースの話題満載 Linuxカーネルの作り出す世界 − ＠IT自分戦略研究所 - ふつうのLinuxプログラミング 青木峰郎 システムコールとライブラリ関数 − ＠IT自分戦略研究所 システムコール・ライブラリルーチン - UNIX の部屋 ltrace 共有ライブラリの呼び出しをトレース。*.soと何を話しているか。 ltrace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 ltrace で共有ライブラリの関数呼び出しをトレースする - bkブログ 404 - エラー: 404 - Linux JF ƒ‰ƒCƒuƒ‰ƒŠ‚ÌŠ
全てのコードに懺悔せよ
ソースコードは資産か、負債か？この問いに自信を持って資産であると断言する方は、残念ながらこの記事とは縁が無かったので回れ右をして帰っていただきたい。今回は思うところが有ったので技術的な話題ではなく、その思うところについて書いてみようと思う。 「ソースコードは負債である」 流行り言葉そのままで申し訳無いが、「ソースコードは資産である一方で負債でしかない側面が有る」と、僕個人としては思う。ソースコードが生み出す価値は資産足り得るがソースコードそのものは紛れもなく負債だ。ソースコードは収穫が約束されない代わりに無限に広げられる畑に例えることが出来ると思う。ソースコードは恵みをもたらすかも知れない。故に、その恵みを最大化するために畑を広げたいと考える。しかし、無闇に畑を広げることは害獣に襲われる土地を増やすことでもあるし、耕し、監視し、水やりをしなければならない範囲が広げるということでもある。つま
クリアなコードに囲まれて - クリアコードでの二年間 - 2013-02-27 - ククログ
クリアコードでアルバイトをしているおやまだです。このたび、二年間お世話になったクリアコードを離れることとなりました。はじめてのククログ記事が、お別れの記事となってしまいました。 この記事では、私がこの二年間で見てきたクリアコードの姿とそこから学んだことがらについて、ご紹介したいと思います。 フリーソフトウェアの会社 クリアコードで二年間働いて強く感じたのは「クリアコードはフリーソフトウェアの会社なんだ」ということです。 思い返せば、クリアコードとのはじまりもフリーソフトウェアでした。二年前、私の公開するフリーソフトウェアをみた社員の方が、うちに興味はないかと連絡をくれたのです。当時は採用プロセスにペアプログラミングがあり、私も社員の方と共に実際のフリーソフトウェアの機能拡張をおこないました。 驚いたのは、そこでおこなった機能拡張が実際のリポジトリにコミットされ、公開されたことです。フリーソ
githubでgemを公開する時に使いたいバッジ - くりにっき
Rubicure，バッジの見本市としてのリポジトリとしても優れてる．— か (@ka_) 2014, 7月 23 と言われたので調子に乗って Rubicure で使ってるバッジをまとめてみます。 結構たくさんあるので必要に応じて使えばいいかと。 CI系 いろいろありますが無料で使えるのはこの辺。 Travis CI drone.io wercker *1 詳しく知りたい人用 CI（継続的インテグレーション）サービスまとめ・14個！ - atskimura-memo CircleCI導入したのでwerckerとの比較も含めてまとめ - 月曜日までに考えておきます Travis CI (Ruby以外でも使える) githubにpushしてもTravis側でテストが開始するのが遅いため個人的に最近は使いたくないのですが、複数のrubyのバージョンやDBの種類で簡単にマトリクステスト出来るのが自分
- テスト熱中症
テスト作業が、開発作業の中にしっかりと組み込まれていない。こうなる と、開発の進み具合を計測することは不可能になってしまう。というのも、あ るの機能が動き始めたのはいつか、またある機能が動かなくなったのはいつか、 まったくわからなくなるからだ。 JUnit を使えば、苦労なく、しかも段階的に、テストスィートを構築 できる。このテストスィートは、進捗状況を把握したり、意図しない副次効果 を見つけだしたり、また開発で労力をかけるべき箇所を明らかにしたりする上 で役に立つだろう。 目次 問題 実例 テストする習慣（プラクティス） 結語 問題 どんなプログラマだって「コードを書いたらテストも書くべきだ」というこ とは知っている。にもかかわらず、実際に書いている人は少ない。「何で書か なかったの？」という質問に対しては、「あまりにも忙しすぎて」という同じ 答えが返ってくる。しかしこれは悪循環のはじま
開発時間短縮のためのプラクティス10選 - give IT a try
このエントリを書いた背景 先日会社で「開発時間を短縮するためのアイデアやノウハウをみんなでシェアしよう」という課題が出されました。 「カウボーイコーディングとコピペプログラミングで技術的負債たっぷりのシステムを作りましょう。そうすれば開発時間はぐっと短くなりますよ」なんてことは口が裂けても言えないので、真面目に考えてみました。 色々あるとは思うのですが、その中でも特に重要だったり、言語や技術を問わずに使えそうなものを10個選んでみました。 どれもまあ、基本中の基本だったり、アジャイル開発だと常識的に行われているようなことばっかりかもしれません。 とはいえ、おいらの会社に限定されるような話は載っていないので、ここにもその時に書いた内容をそのまんま載せておきます。 ただし、あなたの仕事とおいらの仕事は少し違うと思うので、読む前に以下の前提条件を確認しておいてください*1。 このエントリを読む前
さわるのが楽しいコードを設計しよう | システム設計日記
Domain-Driven Design(DDD)の１０章 "Supple Design (しなやかな設計)"は、この本の中では、ちょっとかわった章です。 この章だけは、 ・開発者の視点で ・開発者のための良い設計 にフォーカスしている。 業務の専門家にとってどうか、とか、ソフトウェアの利用者にとってどうか、という議論はまったくでてこない。 ある意味、ドメイン駆動設計らしくない章になっている。 （もちろん、開発者にとっては、面白いし、参考になる内容ばかり） 良い設計ってなんだ 良いソフトウェアは、利用者にとって役立つこと。 でも、この章では、良いソフトウェアのもう一つの側面、「開発者にとって良いソフトウェア、良い設計」に焦点をあてている。 キャッチフレーズは、 "a design that is a pleasure to work with" ふれるのが楽しくなるコード、という感じですか
モノーキ〜デバッグパターン
デザインパターンを勉強していて、ふとデバッグにもパターンがあるよな。 と思って作ってみました。 これって、どこかに協力を仰ぎたいけど、誰に頼むんだ？ （結果的に協力してもらいました。thanks XPMLの皆さん、lemonさん） 何かおもいついた方はこちらへメールか、掲示板へ プログラマ用セキュリティホールパターンってのが欲しいな 例えばSQL injectionとかいうセキュリティホール。 こんなの知らないと絶対やってしまう。 OSとかの設定ではなく、プログラマの設計において注意するセキュリティホールのパターンが欲しい。 集計などはやってもいいので、どこかで有志を募って集めてくれませんかね？ ○デバッグパターンについて ・デバッグパターンとはプログラマから観測できる現象とそれに対する原因と対策をパターンとして登録したものです。中にはアンチパターンという、やってはいけないパターンも存在し
車輪の「再発明」と「再実装」を分けて考える - ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)
ソフトウェア開発で既存ライブラリや先行事例があるにもかかわらず、様々な理由でそれを利用せず、コードやプログラミング技法を再び一から作ってしまうことを「車輪の再発明」と呼び、無駄なコストとして非難される場面が多い。 オブジェクト指向プログラミングのメリットを宣伝する時にも、OOPの機能を活用した再利用可能なライブラリによるプログラミングの省力化という観点から「車輪の再発明をする必要はない」という風に持ち出される事が多い。 自分は「車輪という"アーキテクチャ"の再発明はする必要が無いが、車輪という"物体それ自体"は自分で創る必要がある場合も多い」という意見で、gihyo.jpの記事に絡めたエントリを書いたことがある。：[雑記]いい加減「車輪の再発明」の暗喩を使うのはどうかと思うが。 - ぐらめぬ・ぜぷつぇんのはてダ 今回、さらにすっきりと綺麗にまとめられたエントリを発見したのでこちらでも取り上
テストと言うパートナー #TddAdventJp - 日々常々
TDD Advent Calendar jp: 2011の 12日目です。 前：あなたは写経しますか - pocketberserkerの爆走 次：TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組 テストはパートナー 「何を言ってるんだ？」な感じかもしれませんが、私にとってテストはパートナーです。 私がTDDのコンテキストで言う「テスト」はDeveloperTestです。このテストは開発者の開発者による開発者のためのテストであり、つまり開発者たる私のためのものです。私だけのためにテストは働いてくれます。 テストに対する不安 TDDや自動テストと言う言葉に触れ、「いざテストを書こう」と思った時。もしくはよく知らないままテストコードを書かなければならなくなった時。テストに対して不安を感じると思います。TDDは「不安をテストにする」とか言いますが、そもそもテス
11の項目を設定するだけでJavaScriptコーディングガイドラインが作成できるjsCode | バシャログ。
ゴールデンウィーク中に5年ぶりにフットサルをしてまだ筋肉痛が癒えてないishidaです。社内でフットサル部を立ち上げてみましたが、参加人数が少ないので横浜近辺で一緒に球蹴りしてくれる人を募集中です。 さて今回は、JavaScriptのコーディングガイドラインを作成してくれるサービスのご紹介です。 JavaScript は HTMLやCSSよりも自由度が高いので、 ガイドライン化してコードを統一するのも手間がかかるかと思います。 また初めてガイドラインを作成する人にとっては、 JavaScriptのどこまでをルール化すればいいのかも悩む部分ではないでしょうか。 そんな時にお手軽でJavaScriptコーディングガイドラインを作成してくれるサービスがありました。 11の項目を設定するだけでJavaScriptコーディングガイドラインが作成できる jsCode http://jscode.org
GoCover.io
Shutting down... The GoCover project started in 2014 and shutdown in 2023. Sources can be found on GitHub. What was it? GoCover.io was a service that offered code coverage of any golang package. How did it work? GoCover gathered code coverage by executing a package's tests within an isolated Docker container. What's Next? @ncruces released go-coverage-report, a GitHub Action that will generate gov
Semantic Versioning 2.0.0
english セマンティック バージョニング 2.0.0 概要 バージョン番号 MAJOR.MINOR.PATCH を前提として、 あなたが互換性のない API の変更を行うときに MAJOR バージョンを、 後方互換性のある方法で機能性を追加したときに MINOR バージョンを、 そして、後方互換性のあるバグ フィックスをしたときに PATCH バージョンを、 インクリメントします。 追加のラベルとして、プレリリースとビルド メタデータが MAJOR.MINOR.PATCH フォーマットへの拡張として利用することができます。 序論 ソフトウェア マネジメントの世界には「依存関係地獄」と呼ばれる非常に恐ろしい場所が存在します。 あなたのシステムがより大きくなるほど、あなたのソフトウェアの中へより多くのパッケージを溶け込ませるほど、いつかこの絶望の底にいるあなた自身に気づく、そんな可能性が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブAPIのバージョニングの分析
