ライセンスの選択を恐れる必要はありません - Qiita
この記事はCC BY 3.0に基いて公開されてゐるWebサイトChoosing an OSS license doesn’t need to be scary - ChooseALicense.comのコンテンツ各ページを翻訳し、単一記事として再構成、訳者による補足を追加したものです。 2017年5月9日に開示されたコミュニティガイドラインに伴って、本記事の翻訳部分につきましては削除いたしました。 (この記事が削除または非公開化されない限り、編集履歴からお読みいただくことは可能です。) (訳註: この「はじめに」及び末尾の「訳者による補足」の章は原文にはなく、翻訳者(@tadsan)によるものです。記事の著作権表示及び元Webサイトの利用規約、免責事項、そしてこの記事についての訳者の見解について記します) (この記事の一部または全て ——ただしコメント欄は含まれない—— はCC BY-SA
Matz氏語る「今ソフトウェアはソフトじゃない」 - Engine Yard Blog
先日Rubyビジネス推進評議会主催の第3回Rubyビジネスフォーラムが大阪で開催されました。 Ruby言語開発者、まつもとゆきひろさんが、『インターネットが変えるソフトウェアとビジネス。Rubyを例として』と題した基調講演を行いまいした。 その内容を紹介します。 計算機としてのコンピューター IBMの初代社長トーマス・ジョン・ワトソンの有名な言葉に、「コンピューターは全世界で5台くらいしか売れないと思う」と言ったとされています。 その数字は当時の計算技師の人数とENIACの計算性能から導かれた数でした。 ところが、今ではその数百万倍の処理能力をもつコンピューターが何億台もあります。 去年だけでPC出荷台数は3億台。スマートフォンとタブレットはそれを超える出荷がされています。 コンピューターは計算機としてのみ使われているわけではありません。 インターネットとの接続 今日、大阪まで松江から飛行
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
Java/ServletとJSESSIONIDのURL管理 - Glamenv-Septzen.net
Servlet 2.5 今回主に取り上げるTomcat6, Jetty7で対応しているServlet 2.5の仕様を確認すると、"SRV.7.1 Session Tracking Mechanisms"で以下のように記されています。 SRV.7.1.1 Cookies Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server,
［1］日本人のSE/プロマネが日本語を学び直すべき理由
筆者の本業はプロマネ（プロジェクトマネジャ）ですが、ここ数年は本業をそっちのけにして、ソフトウエア開発に関わるSE（システムズエンジニア）とプロマネを対象に、文章作法の研修やセミナーを実施してきました。これまで研修で接した技術者は6000人、セミナーで接した人は4000人に及びます。 延べ1万人に教えた経験から分かったのは、ソフトウエア開発に関わるSEとプロマネの文章力、すなわち言葉の力が訓練されていないということです。訓練には教材が必要です。そこでSEとプロマネが文章を書くうえで必要となる事柄を「SEとプロマネを極める 仕事が早くなる文章作法」（発行：日経BP社）にまとめました。その中でも特に基本的な事項、別の言い方をすれば、SE/プロマネは知っていて当然であろう文章作法を、本連載で紹介しましょう。 SE/プロマネの仕事の大半は「文章」の作成 残念なことに「SEやプロマネのための文章作法
/.Jに聞け：経産省のシステム管理基準、使ってる？ | スラド セキュリティ
４．プログラミング（４） （1）プログラム設計書に基づいてプログラミングすること。 （2）プログラムコードはコーディング標準に適合していること。 （3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。 （4）重要プログラムは、プログラム作成者以外の者がテストすること。 などだ。いまどきプログラム設計書など作ったことなどないし、納品物として求められたこともない。そもそもプログラム設計書とは何を指すのだろうか。少し大きめの業務システムならクラス数が1000や2000を超えてしまうだろう。それをいちいち設計書を作成せよ、と言っているのだろうか。 世の中のシステム会社は、本当にこの管理基準に従った開発をやっているのだろうか？
コールセンターで人を殺した思い出 - はてな村定点観測所
2014-05-10 コールセンターで人を殺した思い出 債権回収システムの開発 職務経歴には書いていないですが、まだIT業界の駆け出しだった頃、勤めていた会社の都合で商社系のシステム部門に派遣されました。 その商社は誰もが名前を知っている有名なクレジットカードのシステムを受注していて、僕が担当したのはそのクレジットカードの債権回収システムの構築でした。債権回収システムというと聞こえはいいけれど、要は「借金かえしてね！」とお金のない人にお金を返させる仕組みです。僕がやっていたのはカード会社のコールセンターから自動的に債務者に大量に電話を発信する架電ハードウェアの制御でした。 クレジットカードの未払いが貯まるとカード会社のコールセンターのオペレーターから督促電話がかかってくるかと思いますが、大手クレジットカード会社のコールセンターになると、電話は人間が手で掛けているのではなくて、大量の対象者リ
【追記あり】P3:PeraPeraPrv finished its role. - とかいろいろ
予てからの予告通り、昨夜、TwitterAPI1.0はAPI1.1にスイッチし、それに伴い拙作「P3:PeraPeraPrv」は動作不能となりました。(API1.1に対応しない理由についてはこちらをどうぞ) 2007年8月にJavaの習作として開発をスタートし、11月に公開。それ以来Twitterという頼りなくてあやふやな、でも楽しいサービスの普及の一助になれば、特にクライアントアプリの乏しいMacやlinuxのユーザにもTwitterを使って貰えるようになればとリリースを続けてきた本作は、その役目を昨夜、静かに終えたわけです。 5年7ヶ月。フリーソフトとしてはなかなかの長寿命ではなかったでしょうか。 ご存知の様にTwitterは新CEOの就任以来変節しました。インフラを目指してオープンAPIという新しいスタイルを提示し、沢山の開発者*1を魅了することで新しいアプリやサービス、ビジネスを生
保存アイコンでみえてくるアイコンデザインの勘違い
先日 Goodpatch さんが 保存アイコン＝フロッピーディスクの時代は終わった…？ という興味深い記事が掲載されていました。フロッピーディスクを保存アイコンをとして採用するのは古いのではないか、という議論は国内外で何年かに一回はあります。私も 2009 年に変わりゆく「保存」の存在と題してフロッピーディスクアイコンのあり方も踏まえて、今後の保存の姿を模索していました。また、先月開催された Android Bazaar Conference 2013 Spring でも同じ話題に触れています。 アイコンと問題解決について 様々なデザイナーが新しい保存アイコンを提案しているものの、「うん、これは保存だ」と納得できたものはほとんどなかったと思います。ダウンロードにみえるものも少なくありませんし、中には抽象的すぎて何を意味しているのかさえ分からないのもあります。自分たちのクリエイティブアウトプ
販売終了予定の「ComicStudio」、販売/サポート継続を漫画家たちが強く要望 | スラド IT
販売終了予定のデジタル漫画製作ツールの定番、セルシス"ComicStudio"の販売・サポートの継続を漫画家たちが強く要望している。これは後継ソフトの不備が多数存在する中での、ComicStudioの販売終了を危ぶんだ漫画家の野間美由紀氏によって呼びかけられたもので、「コミスタに存続してもらいたいという思いや要望をこの #コミスタ継続希望 のタグで募りたい」とし、それをまとめてセルシスに送る意向を表明した。呼びかけに賛同したプロ・アマチュアを問わず多数のComicStudioユーザが多数の呟きを行い、野間氏自身によって「ComicStudioの継続を希望するTweetまとめ」としてまとめられている。 今回問題となっているComicStudioは、2001年から10年以上バージョンアップを重ねて続いてきた漫画作成ツールで、非常に多数のプロ漫画家もその製作ツールとして使用している事で有名である
東証曰く、システム開発においてコーディング後にはドキュメントは不要 | スラド デベロッパー
2005年に発生した、「ジェイコム株大量誤発注事件」はみずほ証券に大きな損害を与えた。みずほ証券はこの損害の原因の1つに東証の売買システムのバグがあるとして、東京証券取引所（東証）に対し賠償を求める裁判を起こしていたのだが、この裁判が3月18日に結審した（日経ITpro）。これを受けて、日経コンピュータが「みずほ証券-東証裁判の争点を洗い出す」として争点をまとめている。 ここで興味深いのは、東証の開発手法やソースコードに対する姿勢だ。東証はソースコードの修正時にそれに対応するドキュメントの修正を行っていなかったそうなのだが、これについて「コーディングが終了した後はドキュメントは不要」と主張している。いっぽうのみずほ側はこれについて「ソフトウェア工学の知見を無視する暴論だ」として、重大な過失であると主張している。 また、ソースコードには著しい重複があったことが判明しているのだが、これについて
自分が職を失った経緯 - id:anatooのブログ
この記事は、How I Fired Myself.という記事の試訳です。 2010年の7月、私は22歳で、カリフォルニアのあるソーシャルゲームのスタートアップで働いていた。卒業したてで、私にとって初めての本物の職だった。給料をもらってアパートに住んだ。そのころ私は初めて大人になったような気分でいた。 その会社の主力製品であるRPGのコードを書く二人のエンジニアのうちの一人が私だった。大学では哲学を専攻していた。これはどういうことかと言えば、問題に対してどうやって考えればいいかを知っていた一方で、ベストプラクティスや実用的なデザインパターンに関する知識は最低限しか持っていなかった。私は信じられないほどの熱意でもって自分が持っているごく普通のLAMPの知識を駆使した。 私の悩みの種であるゲームデザイナーはしばしばWorld of Warcraftからインスピレーションを得ていた。WoWは、Bl
定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)
いやー、この問題は本当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの？老害なの？」 とか言わないで欲しい。この問題、本当に難しいんだよ！ ■ １度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり
Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤解について - outsider reflex
Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤解について 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « Nexus 7とハードウェアキーボードの組み合わせを実用する Main 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 » 「元のソフトウェアがGPLだから公開できない」という誤解について - Jan 30, 2013 会社のブログに掲載するつもりで書きましたが、タイミング的に発表が遅れてしまいそうということだったので、勢い重視でこちらで公開してみます。 1月31日16時台追記。hide氏の意向についてのこのエントリでの推測が全く
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。お読みのページは後編です。 大規模なテストをどうやって実行しているか 続いて、大規模なテストについて。 1000万件のテストパターンを作っても、それぞれのテスト結果の正解を人手で作っていたら追いつきません。なので、別々に運賃計算ソフトウェアを作って、その答えを突き合わせてチェックしよう、という話です。 例
同僚にコードがひどいと言われたら、どう反応すればいい？ | スラド Slashdotに聞け
「同僚の書く酷いコード、どうやって気づかせる？」というストーリーを先週掲載したが、ひどいと言われた側からのタレこみが本家で取り上げられている。 本家/.「Ask Slashdot: How To React To Coworker Who Says My Code Is Bad?」より 私は今の会社で10年以上働いており、いくつもの製品開発サイクルにかかわってきた。しかし、最近チームに加わった見習いの開発者が、私のコードの出来がひどいと言い出した。わが社のコードベースにはおよそ5万行のコードがある。私のコードに対する苦情は、彼の経験が浅く、コードが何をしているのかを理解していないのが原因だ。彼は頭がよく非常に有望であり、良い質問をしていると思う。しかし、どうすれば彼自身が誰よりも優れているという考えを捨て、時間をかけて内容を学ぶように説得できるだろうか。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
java.lang.OutOfMemoryError #渋谷java
「システム構築に潜むヒヤリハット事例」なる教育ビデオ
NameBright - Coming Soon
Loading...