発声で口を大きく開けると良い声が出るという勘違い 口を開けずに響く声を手に入れる方法：大人の成長研究所：オルタナティブ・ブログ
「発声のときは大きく口を開けましょう」とはよく言われることです。 じつは、私も、以前は、大きく口を開けたほうが良い声が出ると思っていました。 映画「歌魂」でも、合唱団が口を池の鯉のようにぱくぱくと大きく開けている象徴的なシーンがあったのを覚えています。 学生時代の合唱団や劇団クラブは、体育会系のところが多く、しっかりと口を開けていないと叱られるものです。 だから、いきなり「本当は口を開けない方が良い声がでますよ」と言うと「私は今まで何をやっていたのか・・・」と悩んでしまう人もいます。 また、合唱団で４０代以上のベテランの方などは、怒り出してしまう方もいます。 口を大きく開けることが悪いということではありません。 もちろん最初のうちは、口を開ける訓練をすることも良いのです。なぜなら、最終的には「口の中が開いている」ことが大事なので、そもそも口があまり開き難い状態であると、良い声にたどり着くこ
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
何かをやめさせる時の考え方 - β2
仕事では、なにかをしてもらおうとして作戦を練ることがある。じゃあ、なにかをやめさせるというプランはどうだろうか。世の中には、いじめ対策みたいに「なにかを防止したい」というような場合が多くある。こういうとき、どうすると効果があがるのか。 何かをしている人をやめさせたいときに、まずいアプローチというのはすぐに思い浮かぶ。「意志の力で殲滅する」。がんばって、あるいはがんばらせて防止しましょう、のような。人間は何かと意思に頼りたがる。意思で物事が動いていると考えがちだ。それは事実ではなく願望だと思う。 罰を用意すればいいかというとそうでもない。罰は免罪符になってしまうこともある。かつて海外の幼稚園で遅刻に罰金を科したら、むしろ罰金を払えばいいのだと遅刻が増加したという話を聞いたことがある。 ではどうするか。 まず「ガス抜き」だ。元の欲望を、ちょっと似た別の欲望にして受け流す。悪意のあるハッカーに効
まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary
まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」に行ってきました〜。今年初めて行ったイベントなのですが、とてもいいお話を聞くことができました。美しいコードとはどのようなものか、またそのようなコードを書けるようになるためにはどうすればいいのかというお話でした。 以下、まとめになります。僕のメモを元にしたので、まつもとさんが話された内容と多少ズレがあるかもしれません。 そもそもコードとは何か 「コードの美しさとは」という前に、そもそも「コード」とは何か。 ソフトウェアの作成はものづくりではない コードは工業製品ではない。コードは、車とかと同じ工業製品だと思われることが多く、例えば次のような勘違いがある。 日本は「ものづくり」が得意だ。だからソフトウェアも「ものづくり」として取り組めばいい 車のように、ソフトウェアも部品をどんどんコピーして組み合わせばできる 違うよ！全
JavaScriptの巧い書き方 - Archiva
Make a note of it: Web tech, montaineering, and so on. Note: この記事は、3年以上前に書かれています。Webの進化は速い！情報の正確性は自己責任で判断してください。 Webに言語は数あれど、特に玉石混淆の激しいJavascriptの書き方について纏めてみた。間違い指摘大歓迎！ 発端はYahoo!の Eric Miraglia による、YUI 式モジュールの作り方をまとめた記事。ざっくりまとめると、以下の手順になる。 YAHOO.myProject.myModule = function () { //"private" variables: var myPrivateVar = "I can be accessed only from within YAHOO.myProject.myModule."; //"private" m
「まず仕上げる」という話 - やまもといちろうBLOG（ブログ）
話題になっていたので。 いち早く70%～80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話 http://d.hatena.ne.jp/sotarok/20120105/1325698126 でも敗戦処理系の下請けや、制作環境など土台系の仕事をすることの多い弊社からすると、感覚はこんな感じだな、と思うわけです。上記サイトで書かれている通りですよね。試行錯誤の回数を増やさなければならない。 幾つか論点があるとすると、8割というか「まず見てもらえるレベルを提示して、相手に感覚を掴んでもらう」というレベルまでまず仕上げる、というのはクライアントのいる下請けか、上司が圧倒的な指揮権限を持っているプロジェクトなんだろうと思うわけです。 もし、全体工数の半分以下で8割仕上げられるのであれば、残りで想定100％までとっとと作れって話になりますね。でも、だいたい想像できるレベルまでモ
できる！並列・並行プログラミング
現在のマルチスレッドプログラミングの抱える問題点と、代替案をわかりやすく解説いたします。最近登場したConcurrent Revisionsも解説します。
ギリギリまで「まとめに入らない」能力 - Chikirinの日記
会社で働いていた頃、「この人、すごいっ！」と思う人にたくさん出会いました。 中でも私が一番感心したのは、「超ギリギリのタイミングまで、まとめに入らない人たち」です。 なんでもそうですが、何かを作り上げる時には「作る」＋「整える」という二段階の作業が必要です。 最初の「作る」は「中心的な価値」を生み出す作業で、 後半の「整える」は、生み出した価値をお客様に説明しやすく＆売りやすくするため、細部や体裁を整え、きれいにパッケージする、みたいな作業です。 この「作る」から「整える」に移行するタイミングを「まとめに入る」と呼びます。 たとえば 10日後に締め切りの企画書があるとしましょう。 このとき、デキる人は最初の 9日間は「まとめ」についていっさい意識せず、思考をどんどん発散させて、考えることに集中します。 一方、6日目くらいからは「まとめ」を意識して「落としどころ」を探りに入る人もいます。これ
NO TEST, NO LIFE. NO DOC, NO LIFE - latest log
uupaa.js や mofmof.js には {@hoge 〜 }@hoge のようなコードブロックを切り落として Minify する機能があるので、「ソースコードにテストもドキュメントも全部埋め込むことが可能だな〜」って3年程前から考えてました。 そこで、Function.prototype.spec というメソッドを追加し、これにスペックを書き貯めたらどうだろうか(?)とか考えました。 たとえば Array.range(1,7) で [1..7] 的な連続した数値の配列を生成する Array.range 関数があったとすると // Array.range - range generator function Array_range(begin, // @param Number: begin end, // @param Number: end filter) { // @param
ノマドって有名大学卒業した人か有名企業出身ばっかり
白饅頭（御田寺圭／光属性Vtuber／バーチャルツイッタラー） @terrakei07 ノマドの人たちの生き方は、常々耳にするようになった、生き方の多様性に通じるとは思う。けれど、その一方でわずかにすっきりしないのは、彼らは仮に既成の価値観から降りなくても、十分に上位層に食い込めたであろう、環境にも才能にも秀でた人たちであるように見えることだ。 2011-08-20 20:52:21 白饅頭（御田寺圭／光属性Vtuber／バーチャルツイッタラー） @terrakei07 ネットで有名なノマド（的生き方をする自由人や個人事業者）って、たいてい名門大学を出てたりして、あーすごいな、とか思うのだけど、そうでない人たちがこういう人の真似をすると、普通に働くより競争が激しそうな業界だから、エリートノマドたちの養分になりそうで怖いな、とか思ったりする。 2011-08-20 20:54:13
最近のアプリケーション開発で理解しておかないといけない基本事項 - 丸井綜研
とくにMacやiPhoneのプログラム開発で最初にわからなくなるのがこのあたり。Appleもそれは理解していて、Your First Mac Applicationの中のUnderstanding Fundamental Design Patternsという章にまとめてあります。 僕もまだ慣れてないので、その文章を読んでの現時点での理解を下にまとめておきました。 Model-View-Controller その昔、僕がBASICでプログラムを書いていたときにはデータもコードも一緒くたで、すぐにスパゲッティ・コードになったものでした。Javaのようなオブジェクト指向言語を使うようになって、データ構造部分とその表示部分とは切り分けた方がいいと学びました。 たとえばRPGを作っているときに、体力点とか技術点のような主人公の基礎データを保管・管理する部分と、それらを画面に棒グラフなどで表示する部分
ふき出しのレトリック 〜マンガの修辞学〜
2008/05/25 : サイトを移転（「いま」見ているのが、移転先のサイトです） 2008/10/04 : 「使う目的別のまとめページ」をバージョンアップ 2008/10/04 : 倒置反復に画像を追加して加筆 2008/09/26 : 脚韻のページにある内容を、かなりに変更 2008/09/20 : 島村瀧太郎（抱月）『新美辞学』のページを作成 2008/09/07 : 隠喩に画像を追加して、加筆 2008/08/30 : 設疑法を追加 2008/08/23 : 直喩に画像を追加して、加筆 2008/08/16 : 韻文を追加、押韻・頭韻・音数律に加筆 2008/07/19 : 祈願法を追加、緩叙法（付加）に画像をつけ足して加筆 2008/07/18 : カウンタが100,000を突破（祝） 2008/07/12 : 「使う目的別のまとめページ」というものをつくり
テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる, tDiary 3.0.2 リリース - 会長@腹部日記(2011-04-29)
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
大学時代の線形代数のテストで
http://anond.hatelabo.jp/20110717152546 元増田の話で、思い出したんだけど、 大学時代の線形代数のテストの話。 テスト勉強してて、全然わからなからなくて、 友達と一緒に勉強してても、お互い分かっていない同士だから、 あんまり効果なくて、「試験ヤバいな」と思っていたの。 で、テスト当日、数学の出来る奴と雑談してて、 そいつが「ハミルトンの四元数」とか、 「射影」の意味とか、使いどころとか、（検索してて思い出した「準同型定理」） 果ては「ブルバキ原論」の話とかしだして、 そんな感じで30分ほど雑談兼レクチャーを受けたの。 それで、試験ですよ。 なんかさ、テスト問題がすげー簡単に見えたの。 「この問題、さっき話に出てたハミルトンの四元数じゃん」とか。 たった30分の雑談が、独学の試験勉強10時間分以上の効果が あったんじゃないかと思う。 講義中、先生はさ、教
DSLによる要求獲得でスーパーアジャイル
２０１１年７月８日（金）に行われた第２回ＴＰＳ／アジャイル研究会での発表資料です。DSLを中心とする要求獲得がもたらす効果を実例を交えながら解説する内容です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kakoe1997
アジャイル開発とTDDを半年間実践してみた顛末と、これから
削除フラグのはなし
How to make Awesome Diagrams for your slides
xUTP Chapter19 (2). Testcase Class