追記したよ！ 注意 Mac にもいいところはあるけど書いてない Windows の方がいいとは言ってない ハード / MacBook Pro 14インチ 会社から貸与されているのは MacBook Pro 14インチなのでそれについて。他のは知らない。 JIS キーボード キーボードは US でも JIS でも選べたんだけど、慣れてるので JIS を選択した。 そしたら変な配列のキーボードだった。「1」の左にキーが無い。数字キーの列が全体的に左によってる。「1」が「TAB」よりも長いってどういうこと？ [追記] 対策と言っても外付けキーボードを使うくらい。自分は ThinkPad トラックポイントキーボード II を使ってる。 会社に行くときもキーボードを持っていってる。薄くて軽いので良い。 重い 今どき 14インチで1.6kg って重すぎるでしょ。ThinkPad T14 の 1.3kg

これは「Rubyist近況[1] Advent Calendar 2021」の6日目の記事です。 adventar.org 自称 Rubyist なので近況を書きます。 2021年10月末で30年ほど勤めた富士通グループを退職しました。 11月からは SmartHR という会社で働いてます。 3年ほど Ruby は仕事ではあんまり使ってなかったのですが、また Ruby を仕事で使うようになりました。 会社から配布された PC は Core i7 メモリ32GB の MacBook Pro なんでかなり人権がある感じなんですが、人生初 Mac で１ヶ月位経ってもまだ慣れなくて、VM で Ubuntu Desktop 入れようか迷ってます。 近況は以上です。以下は富士通グループの入社〜退職までのメモ。長いので読まなくていいです。 1991〜 設立７年目の今はなき「富士通長野システムエンジニアリ

こんな記事がありました。 gihyo.jp これはMacユーザー用の書籍の宣伝記事らしいのですが、「Windowsを使ってる人のためにMac側がひと手間かけてあげよう」なんて殊勝なことをマカーが言うとは時代も変わったもんです。（[追記] はてブのコメントを見たらさすがマカーという意見が並んでて安心しました） まあ私はWindowsユーザーでもMacユーザーでもないのでどうでもいいのですが、文字化けなネタなので食いついてみます。 記事中に、「付物出稿.zip」というファイルを開いた時の画像が載ってます。 文字の並びからして、UTF-8文字列をシフトJIS(CP932)とみなして表示してしまった文字列でしょう（「繧ｫ繝上ｙ繝ｼ繝輔か繝ｫ繧ｿ繧･」の元の文字は「カバーフォルダ」で、「蟶ｯ繝輔か繝ｫ繧ｿ繧･」は「帯フォルダ」）。 つまり、Macはファイル名をUTF-8でZIPに書き込み、Wi

この記事は、おっさんの自分語りと昔話なので、あまり読む価値はないです。 もう１ヶ月くらい前になるのですが、OSS貢献者賞を頂きました。 最近はあまりOSSに貢献するようなことをしてる自覚はなかったので、なぜ自分が候補にあがったのか謎でした。OSS貢献者賞のページによると、 影響力のある開発プロジェクトを創造、運営した開発者やグローバルプロジェクトにおいて活躍する卓越した開発者及び普及に貢献した方を表彰するもの ということらしいです。創造や運営してないし、たぶん卓越した開発者でもないので、「普及に貢献した」だろうと思い、じゃあ最近のことじゃなくて過去の実績が評価されってことならいいかと、受賞させていただくことにしました。 ちゃんとした受賞理由は発表のページに載るまで知らされてなかったのですが、予想通り MySQL 関係でした。 MySQLの初期の日本語化パッチを作成し、国内での普及に大きく貢

(これは 6/6 に書きました) アジャイルプロセス協議会主催の「ソフトウェア技術者サミット in 長野」というイベントに参加してきました。 アジャイルプロセス協議会は、こういうイベントを年に2回くらい地方で開催しているらしいです。 ソフトウェアにまつわる３つの疑問 上田出身の湯本さん(@yumotsuyo)がゲスト講師でした。 以下メモ。 HPはアジャイル。アジャイル以外の話は出てこない。アジャイルが当たり前。 テストはどこまでやれば十分か テストを設計するってどういう事か テストを開発するとは何か TDDはテスト？ 開発をドライブする手段だから品質保証しなくてよい？ 品質保証の人たち、うざい 品質はどうでもよい？ 品質保証が最後にシステムを確認するのはテスト？ 品質保証の手段だから開発のことは知らなくて良い？ 開発者は言うこと聞かない！ 「造り」を無視して品質が保証できる？ SWEBO

短い時間だったのでかなり駆け足でした。もっとじっくり聞きたい感じでした。 以下適当なメモ。嘘かいてあるかもしれません。 なぜ今アジリティが求められる？ ほとんどの会社が5年しないうちに出て行ってしまう 残る会社は戦略を変えつづけている 顧客ニーズへの俊敏な対応 アジャイル導入の効果は魅力的 導入により改善されたと答えている人の割合 生産性82% 品質87% 顧客満足度78% コスト72% IBMソフトウェアグループでの開発手法の変遷 1980年代 ウォーターフォール 1990年代 反復型開発 現在 アジャイル開発 アメリカでは70%以上がアジャイル技法を使っている 日本では 15%〜20% 反復型は50%以上 普及が進んでいる アジャイル開発の本質 アジャイル開発を企業に導入する際の課題 規模に関係なく適用可能なプラクティス 大規模だからこと考えるプラクティス アジャイル開発手法の共通点は

最初に、開発プロセストラックのコンテンツ委員の和田さんから挨拶がありました。 漆原さんモデレータで、製造金融業界で基幹業務をアジャイル開発した事例を聞くパネルでした。 アジャイルを成功させるにはお客さん次第。 以下適当なメモ。嘘かいてあるかもしれません。 ウルシステムズ 漆原さん 今までの「アジャイル開発」 理想目標←→弊害・懸念 「幸せな開発をやりたい」←→アジャイルが目的化、ユーザ理解が希薄 大事なところから作りPDCAサイクルを回す←→採集成果物が不明、責任所在が曖昧 少数の優秀なメンバーで切れ味良く仕上げる←→小規模Webのみ、業務系はムリ！ 開発工程の無駄を省く←→ちゃんと設計しない、ドキュメント書けない 本セッションの目的 基幹業務システムまでアジャイル開発しちゃいました！ 効果、苦労、リスク、工夫、反省、学び 東邦チタニウム 浜津さん チタン生産部門の部門長→リーダ→チームリ

スライドが公開されてるのでそっちを見た方が正確です。 けど、一応メモったものを載っけておきます。 安定稼働と高性能を支える要素 問題の大半はディスクI/O 製品の品質に対する目を向ける 「俺が安定版と言えば安定版なんだ！」というものもある 一般解を求めすぎない 汎用性を高くすればするほど効率は悪くなる 良いところよりも悪いところを見る 悪いクエリが1個でもあると、すべてが止まることがある ボトルネックになっていないところをどれだけ最適化しても全体のパフォーマンスはたいして変わらない データベース以外にも目を向ける アプリケーションの性質をある程度知っておく OSSを責任転嫁の道具にしてはいけない Linuxのチューニングと安定運用 メモリ管理 メモリを十分に取り、ダイレクトI/Oを活用する innodb_flush_method=O_DIRECT スワップ制御とOOM Killer スワッ

熱かったです。ただの１セッションではなく、デブサミ全体を代表する基調講演と言ってもいいくらいだと思いました。 長野からだけど朝イチで行ってこのセッションを聴講できてとても良かったです。 以下適当なメモです。 第1部 環境の変化により途中でプロジェクト終了 残ったのは大量の紙 環境の変化は止められない ソフトウェア開発で何を実現したいのか 必要とされるソフトウェアの提供が困難 1. 変化に対応できない 2. 価格に対する納得感がない 3. 必要なタイミングで手に入らない 変化 外的変化 経済環境や政治環境 内的変化 状況が進み理解が深まり分かるようになる 受託開発一括請負における変化 変化=仕様変更 変更管理は開発を安全に遂行するためのもの 受注側は別料金 発注側は固定料金 ゼロサムゲーム 仕様変更管理なんて言ってるレベルでは変化を受け入れることはできない 人月 コスト算出の基準 リスクが排

4人がそれぞれ自己流の勉強方法を紹介するというセッションでした。 全員が「アウトプット重要」と言ってました。 以下メモ。嘘書いてるかもしれません。 庄司さん OUTPUT < INPUT OUTPUT すると INPUT が大きくなる ブログなどに書く 教えてくれる ググれる 外部記憶装置に頼るの大事 人に聞く みんなやさしい 書く コピペじゃなくて写経 読む Google Code Search CodeRepos どう書く.org RSSで読む http://mvnrepository.com の RSS はてなアイディアの新着 RSS 堀さん Webサイト 各種ソーシャルブックマーク 仕様書 Webサイトのソースコード JavaScript はソースが見れる JavaScript のコード整形 http://jsbeautifier.org/ ブログ 勉強会 ライブラリ 書籍 サンプ