タグ

programmingとProgrammingに関するraituのブックマーク (1,069)

  • Programming Languages Influence Network | Exploring Data

    Loading the data may take a while, please be patient... Graph Navigation You can zoom in and out the graph with the mouse wheel. You can move the graph by clicking and holding the left mouse button and moving the mouse. Language Information When you click on a language node in the graph a modal window with information about the language will be displayed. Language Search Search for a language name

    raitu
    raitu 2012/10/05
    「プログラミング言語同士がどう影響を与え合っているのかを示した相関図」
  • ソースコードを表示するためのフォント「Source Code Pro」をアドビがオープンソースで無料公開 - Publickey

    プログラミングやマークアップなど、コーディング作業のときにソースコードを表示する目的で開発されたフォント「Source Code Pro」を米アドビがオープンソースとして無料公開しました。24日(日時間24日深夜)に開催された同社のイベントCreate the Webで発表されました。

    ソースコードを表示するためのフォント「Source Code Pro」をアドビがオープンソースで無料公開 - Publickey
    raitu
    raitu 2012/09/25
    日本語非対応?ためしてみるか
  • 自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)
    raitu
    raitu 2012/09/24
    乗り換えを考慮すると常に鉄道全社の運賃改定を全ての改札機に適用せねばならず自動改札機が稼働中でもアップデートできるようにしたとか
  • サイバーエージェントの中の人に「なんで、あんなにリア充なんですか」って聞いてきた話 - ゆううきブログ

    寺子屋ギークという2日間のイベントに参加してきた.Cookpad,Mixi,サイバーエージェント,サイボウズなど名だたるWebっぽい企業の方からWeb系のギークっぽいお話を聞いてきた. もっとも,聴衆の方はあんまりWeb系ではない感じだった. Web系はRubykaigiに行ってそう.企業の中でもドリコムが一番狂っていて楽しそうで、名前をidで呼ぶらしくて良さそうだった. 2日目に,後ろに座っていた女の子もドリコムがおもしろそうと言っていた. @yoshitetsu さんに「東京来る予定ある?」みたいなこと聞かれたので,その折にはぜひ遊びに行きたい.id:jkondo 社長の「新サービスはだいたい流行らない!」 は名言だった. サイバーエージェントとか サイバーエージェントについては以前からウォッチしていて(入社式的な写真)派手な女の子とかたくさん居てリア充っぽくてひどい感じでdi

    raitu
    raitu 2012/09/17
    id:jkondo 社長の「新サービスはだいたい流行らない!」 は名言だった」だれかツッコめよ
  • 米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ

    "米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ

    米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
    raitu
    raitu 2012/09/04
    基本的に同意だけど、コメント網羅するのはどうかな。コメントとコードの不一致が発生しやすくなる。できるだけ変数名、関数名、構造を分かりやすくして、コメントは減らしたほうが良いと思うが。
  • オブジェクト指向できていますか?

    3. 自己紹介 1992年~1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年~現在 日工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。

    オブジェクト指向できていますか?
    raitu
    raitu 2012/08/29
    スライド17枚目、コーディング規約が宗教扱いでワロタ。/コードの見やすさ最優先な感じ。ハード制約の厳しい組み込み向けではない。組み込みではまだまだ本質的なオブジェクト指向は厳しいということでもある
  • 良いエンジニアの育て方 - ひがやすを技術ブログ

    人を育てるというのは、とても難しい。 なぜなら、育てる方も未完成な人間だから。 ちょっと経験値のある未完成な人が、経験値の少ない未完成な人と、ともに冒険をし、ともにレベルをあげていくことが、人を育てるってことだと思う。 人を育てようと思うと、どうしても上から目線になってしまう。上から目線だと気持ちも相手に伝わりにくい。気持ちが伝わらないと相手もうまく成長してくれない。 だから、人を育てる機会があったら、ともに冒険をする仲間を持ったと考えよう。きっとその方がうまくいく。 それでは、自分の話をしよう。自分というよりは自分たちの話かな。 2010年、自分は、昼間、ブラ三をやりながら、新規ビジネスの企画を考えたり、プロトタイプを作っていたりしていた。ブラ三をやっていたのは、当然ソーシャルアプリというものを学ぶためだ。ブラ三の能力はかなり向上したけど、仕事ではたいした結果が出せなかった。特に企画考え

    良いエンジニアの育て方 - ひがやすを技術ブログ
    raitu
    raitu 2012/08/28
    適切な大きさの問題を用意する、ということについて。マネジメントで最も重要かつ難しいところかと
  • コードレビューいろいろ - steps to phantasien

    コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque

    raitu
    raitu 2012/08/20
    今のプロジェクトでは、かなりインスペクションをきっちりやってる。あれはあれでバグが結構抑えられてよい。
  • 変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々

    2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod

    変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
    raitu
    raitu 2012/08/17
    俺なんて全行に行番号がコメントされたコードを見たことあるよ…会社のルールなんだそうだ。しかもかなりの大手
  • コードレビューについて - camlspotter’s blog

    このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや

    コードレビューについて - camlspotter’s blog
    raitu
    raitu 2012/08/15
    コードレビューに関する良記事。そのコストの高さを踏まえた上で、机上レビューを中心に進めると。Pull reqは便利だけど金融系コードだとGitみたいな分散レポジトリは統制取りにくく忌避されがち。金融でGithubは論外かと
  • 長文日記

    raitu
    raitu 2012/08/15
    ブロック組み合わせでプログラミングさせるのは教育に有効どうかの検証事例
  • こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ

    最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい!どの口がアジャイル出来るって言ってるねん!」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを10年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか?」と思ったところから来ている。 それが、今やもしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ

    こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
    raitu
    raitu 2012/08/14
    いいたいことはわかるし間違ってないと思うけど、綺麗なコードがわかるセンスが必要というわりにフォントいじりがやたら下品で信憑性だだ下がり
  • ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!

    続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解:既にあるソフトウェアを流用し

    ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
    raitu
    raitu 2012/08/08
    ソフト開発6つの誤解「流用すりゃ早く作れる」「ソフトは簡単に後で修正可」「誰が作っても中身は同じ」「共通部品から先に作れる」「人を増やせば一度に沢山作れる」「正確な見積もり出せる」
  • 職業PGにわかるFizzBuzz - 日々常々

    なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。

    職業PGにわかるFizzBuzz - 日々常々
    raitu
    raitu 2012/08/08
    これがExcel方眼紙か。初めて見た。あとループについての記述がないのでOUT。
  • アプリ開発私塾に小学生 スマホが迫るIT教育の変革 - 日本経済新聞

    では専門的なIT(情報技術教育は義務教育を終えてからでないと受けられない――。そんな状況を打破しようという動きが広がってきた。生まれたころから、デジタル機器とネットに囲まれて育った「デジタルネーティブ」の世代の子どもたちが、高度なIT教育を受ける場を求め始めているのだ。きっかけはスマートフォン(高機能携帯電話=スマホ)の爆発的な普及。将来の就職も見据えて、親たちも最先端のITを学ぶ環境を求

    アプリ開発私塾に小学生 スマホが迫るIT教育の変革 - 日本経済新聞
  • GitHub - google/styleguide: Style guides for Google-originated open-source projects

    Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. “Style” covers a lot of ground, from “use camelCase for variable names” to “never use global variables” to “never use exceptions.” This project (google/stylegu

    GitHub - google/styleguide: Style guides for Google-originated open-source projects
    raitu
    raitu 2012/07/26
    Googleが出してるコーディング規約集。C++,Objective-c,Python,HTML/CSS,JavaScript,XMLなどがある。http://google-styleguide.googlecode.com/svn/trunk/ を見るとJSON guideやeclipseのstyle xmlなんかもあるようだ。
  • C++ Style Guide

    Benjy Weinberger Craig Silverstein Gregory Eitzmann Mark Mentovai Tashana Landray This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there's an "expand all" at the top o

    raitu
    raitu 2012/07/26
    Googleが出してるC++のコーディング規約。結構基本な感じで導入しやすそうではある
  • ちょっとひと言 - 物言わぬ多数派: Visual Basic 6 が今でも成功している理由

    注意 このページにアクセスするには、承認が必要です。 サインインまたはディレクトリの変更を試すことができます。 このページにアクセスするには、承認が必要です。 ディレクトリの変更を試すことができます。 物言わぬ多数派: Visual Basic 6 が今でも成功している理由 David Platt マイクロソフトは最近、Windows 8 の有効期間は Visual Basic 6 アプリケーションが「動作する」よう、互換性を確保する期間を延長することを発表しました (詳しくは今月の編集長のコラム、「老兵は死なず」をお読みください)。最初に Visual Basic 6 がリリースされたのは 1998 年なので、Visual Basic 6 アプリケーションは少なくとも 24 年にわたってサポートされることになります。Windows 7 (2009 年) と互換性がない Microsoft

    ちょっとひと言 - 物言わぬ多数派: Visual Basic 6 が今でも成功している理由
    raitu
    raitu 2012/07/13
    VB6が24年サポートされ続けるのは何故かについて。これ日本の記事かと思いきや著者外国人なんよな
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type
    raitu
    raitu 2012/07/10
    「コンピュータの中に複数のCPUがあれば「マルチコア」になり、ネットの向こう側にあると「クラウド」に」「ソフトウエア開発の未来を先読むキーワードは、「たくさんあるコンピュータをいかに使いこなすか?」」
  • あなたがmz-700でプログラムを作った方がいい10の理由

    コンピューター業界はめまぐるしくトレンドが変わっていく。とにもかくも流れが速い世界だ。単に速いだけでなく年々高度な技術が必要とされ、それについていくだけでも大変な人も多いだろう。そして、あまり儲からないスマートフォン市場にうんざりしている人もいるのではないだろうか。また、IT業界はサービス競争の嵐だ。この嵐に巻き込まれたら、ひとたまりもない。 そんなひどい状況から抜け出して、もっとのどかにプログラミングを楽しみたいという人も多いのではないだろうか? そんな人にお勧めなパソコンがmz-700である。昨今のプログラム開発にうんざりしている人は、ぜひmz-700でプログラミングしてみるとよい。ここでは、あなたがmz-700でプログラムを作った方がいい10の理由をあげてみよう。 (1)安定したハードウェア 安物のAndroid端末や初期のWindowsマシンの不安定さに苦しめられた人もいるのではな

    raitu
    raitu 2012/06/26
    「mz-700は抜群に安定している。1982年に発売されてから2012年まで一度もモデルチェンジをしていないのだ」「電源を入れてから起動に1秒すらかからない」