Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find

ポール・マクマホンはDoorkeeperの共同設立者であり、現在は同社代表を務めています。2010年9月からはTokyo Rubyist Meetupも主催しています。 今回のDoorkeeperの料金体系変更により、これまで無料だったサービスを有料でご利用いただくよう多くの皆さまにお願いすることになりました。最悪ですよね。かつて無料だったものにお金を払うなんて、決して嬉しいことではありません。それを知っていながら、なぜ今回の変更に至ったのか。その背景にある僕たちの考えを詳しく説明させてください。 まず最初にお伝えしたいことは、Doorkeeperはサービス継続のために必要な収益を十分に上げていなかったということです。Doorkeeperは、僕自身ともう一人の共同設立者であるミヒャエル、そしてパートタイムのサポートメンバーというごく少人数のチームで、少ないコストで動いています。前払いチケッ

小学校以降〜大学受験まで、学年に関係なく、受験を控えている or 受験をするかもしれない子どもの親に向けて、親にこそ知っておいて欲しい効率的な勉強方法を有給ニート中の有り余るヒマを注ぎ込んでまとめてみたスライド。Read less

一昨日、福井県の「ふくい産業支援センター」さんが主催されたセミナーで、標題の講演をさせていただきました。資料はこちら。 参加者約70名のうち、75%は18歳以上の大学生・専門学校生、15%が高校生・高専生、10%が小中学校。これまでエンジニアの中で話をする機会は多々ありましたが、学生さんばかりの中で話すのは初めてでした。 内容 内容としては、「プログラミングでこんな感じでメシを食ってる人がいる」という一つの参考例として自分の働き方を紹介しつつ、プログラマとしてとりあえずやっていけるようになるまでの話と、フリーになってからおもしろい仕事を得るためにどんなことを考えながら働いているか、の3部構成でした。 50分と長尺の講演だったので、最後にFAQをくっつけて時間調整できるようにしておいたのですが、6つぐらい用意しておいたうち2つぐらいしかしゃべれず。話したうちのひとつは「お金の話」だったのです

社内向けの教育資料を、ど素人でもわかるようにと思いながら作っていて、じゃあ「わかりやすい」って何だろうって考えてた。今まで読んできたいろんなわかりやすかった本とそうでない本を思い浮かべながら、一般的にここを注意すればわかりやすさを確保できるだろうっていうポイントを一旦まとめておこうと思った。そうしてまとめてみると、本に限らず人に何かを伝えること一般に適用される話だなと思った。 読む側の負担を減らす わからない＝理解をはばむ障害物がある。この障害物を取り除く／回避する作業が「わかる」ために必要になる。その作業を、作者ではなく読者が負担するとき「わかりにくい」本になる。 日本社会だと情報の受け手の側がこの「わかる」ための作業を負うことでコミュニケーションを成立させる傾向にある。空気を読むというようなことだ。そのため発信者側が事前に手を尽くしてわかりやすく発信するというのが苦手で、相手が汲み取っ

これであなたのQiita記事もランキング入り！？@jnchitoによる編集リクエスト解説（解説動画付き）Qiita日本語 はじめに みなさん、コードを書くのは得意ですか？ ・・・はい、みんな得意ですよね！ じゃあ、文章を書くのは得意ですか？ ・・・あれ？急に声が小さくなりましたね（苦笑） たぶん、自信を持って「わかりやすい文章が書けます！」って言えるエンジニアの方は少ないんじゃないかと思います。 というわけで、この記事では実際の「編集リクエスト例」を使って、わかりやすい技術記事を書くポイントを説明します。 説明で使うQiita記事 説明で使うQiita記事はこちらです。 nested_form で子レコード間の関連を検証する - Qiita 内容としてはRailsでよく使われる nested_form というgemの応用的な使い方を説明しています。 編集リクエスト前の記事 上のリンクはすで

はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き

第14回 中国地方DB勉強会 in 福山の登壇資料です。 https://dbstudychugoku.github.io/events/event-014.html 合わせてこちらのYouTube動画を見ることをオススメします。 PGCon 2014 Tokyo【D3】PostgreSQL SQL チューニング入門 入門編（下雅意 美紀） https://www.youtube.com/watch?v=gxsBi-6ub3k&nohtml5=False

Rails開発におけるRSpecの使い方を学ぶことができる技術書「Everyday Rails」の期間限定チャリティセールが開催されています。翻訳者の伊藤淳一氏によると、2016年5月31日まで最低購入価格が16ドルから9ドルに値下げとなり、期間中に発生した収益はすべて熊本地震の災害支援のために募金されるようです。 Everyday Railsは、実際に動作するRailsのサンプルアプリケーションを使いながらRSpecを使った実践的なテストの書き方を学ぶことができる技術書です。電子書籍の形式はPDF、EPUB、MOBIに対応し、日本語版独自の追加コンテンツとして「RSpecユーザのためのMinitestチュートリアル」」もダウンロード可能となっています。 RSpecやMinitestの参考書を探していたかたはこの機会にどうぞ。

私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい

みなさんが思う「かっこいい音楽」ってなんですか？ 考えてみると難しいものですよね。 「泣ける」とか「楽しい」って気持ちを表した言葉なのに、「かっこいい」ってソトガワの話…。 でも同じように音楽を形容する言葉として使われます。 だから人それぞれ「かっこいい音楽」ってあると思うんですけどね。 今日はぼくが思う「かっこいい音楽」をみなさんにお届けします！ やっぱりバンドマンですから、かっこいい音楽=ロック！ そして「今さら人に聞けない王道」なロックミュージシャンたちになっています。 コレ、つまるところ現代に通づる「かっこいい」の概念をつくってきたバンドたちです。 このリストを通じて「かっこいい」の意味を共有できたらうれしいですね。

By DHH 私はコペンハーゲンの街はずれのミドルクラスよりちょっと下くらいの家庭で育った。スカンジナビアの外はどこでも「貧乏」という社会経済的なレッテルが貼られていたが、デンマークのセーフティー・ネットとサポート・システムは国内状況を何とか改善しようと最善を尽くしてくれていたのだ。 中央が私。手作りの服を着て、同じく手作りの忍者の武器を構えている。イェイ！とここまで読んで心配しないで欲しい。これから語るのは「無一文から大金持ちになったサクセス・ストーリー」ではない。しかも、私は「英雄的なことをたった1人で成し遂げた」と吹聴して回るのが大嫌いなタイプだ。私は無一文どころか政府が支援する産休、育児、教育制度、現金支給の恩恵まで受け、さらにはAAB（労働組合による住宅支援協会）が用意してくれた住宅で不自由なく育った。それに私の母は、全く余裕のない家計の帳尻を「1番安い牛乳を買うために自転車で1

はじめに 先日、この記事を読み内容が素晴らしすぎてCSSを勉強したくなったので、ハンズオンの課題をやってみました。 blog.jnito.com 先に言っておくと、私には難問でした。 CSS知ってる人からすると簡単なのかもしれませんが、1つも解けませんでしたよ。 1問目：グローバルナビゲーション 完成形 結果 display: inline-block を使いましたが、最後の要素が落ちてしまう状況が解決できず断念。 次に、float: left を使いましたが、左右の余白を解決出来ませんでした。 結局、回答を確認（5種類の回答が用意されていました）。 display: table や Flexbox は知りませんでした。 個人的には、Flexbox がかなりいい感じだと思いました。 ポイント リストを横並びにする方法は色々ある display: table の使い方 以下の記事が分かりやす

はじめに さる2016年1月9日、西脇.rb＆神戸.rbの合同勉強会として「RubyistのためのCSS勉強会」を開催しました。 主催者の僕自身が「参加して良かった！」と思えるぐらい有益な情報がたくさん詰まった勉強会になったので、今回のエントリではこの勉強会の内容を紹介します。 もくじ ちょっと長いので、先に目次を載せておきます。 はじめに もくじ 講師は合同会社フィヨルドの町田さん！ この勉強会で講義してもらったテーマ 座学編 Railsの app/assets/stylesheets 内のディレクトリ構成例 最近注目を集めているAtomic Designについて 3種類のリセット系CSSの特徴について 変更に強いマークアップのルールについて プログラマとデザイナの協業について ハンズオン編 進め方の具体例 1問目：グローバルナビゲーションの作成 2問目：アラート画面の作成 3問目：記事

Rails 5.0.0.beta1: Action Cable, API mode, Rails command Rails 5.0! Can you believe it? We only just celebrated the tenth anniversary of Rails 1.0 a few days ago. Time flies when you’re having fun with good friends, and we’ve never had more fun or better friends in the Rails community, so no wonder it’s going swoosh! Now this is just the first beta release, but Rails 5.0.0.beta1 is already running

こんにちは！freee ソフトウェアエンジニア @toshi0607 です。 この記事は freee Engineers Advent Calendar 2015 14日目です。 自己紹介 去年かいたもの 見積書 契約書 提案書 稟議書 はじ 今年かいたもの Ruby C# freeeに転職してもう少しで1年。それまではIT業界で営業をしていました。 週末にコードを書いていたものの、実務レベルにはほど遠い…。そんな僕は今でもまだエンジニアとしてお仕事させてもらっています。 今日はそんな風に生き延びることができた所以やエンジニアを育てるfreeeの文化について順番に紹介していきたいと思います。 恐怖の入社前課題 内定から数日後、食い気味にやる気をアピールしたかった僕はCTOにお願いして入社前課題を求めました。結果、以下全てを3ヶ月でマスター勉強することに…！ Ruby on Railsチュー

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up