「【Rails Developers Meetup 特別編】『プロを目指す人のためのRuby入門』出版記念イベント&リファクタリングコンテスト」で使用したスライドです。 https://techplay.jp/event/647072
![わかりやすい技術記事を書くための心構えとテクニック / #railsdm 20171206](https://cdn-ak-scissors.b.st-hatena.com/image/square/a7716af4cb3ea1658ebf6da1c6c498a959950565/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F6ee291ae91c1461e8c6330fc48d885b6%2Fslide_0.jpg%3F9118953)
This document discusses different architectures for structuring GUI and state management in iOS applications. It covers common patterns like MVC, MVP, MVVM as well as concepts like separation of presentation and domain layers. Specific topics covered include screen state, presentation state, session state, record state, observer synchronization, flow synchronization, and how these relate to archit
JJUG CCC 2017 Fallでの発表資料です。
Timers Tech blog での2回目の投稿となります。 サーバエンジニアの長南です。 先日弊社CTOのアマドの「コミュニケーション能力はエンジニアにとって必要不可欠な能力である」という記事がありました。 techblog.timers-inc.com 考えてみると、開発の現場はコミュニケーションの連続です。UI/UXは開発者とエンドユーザの間でのコミュニケーションの場ですし、この Blog を表示されるために行われる HTTP や HTTPS、よりレイヤーの低い TCP/IP といったプロトコルもコミュニケーションのひとつの形です。そもそもコードを書くということ自体が人間とコンピュータの間のコミュニケーションと言っていいでしょう。 実際の開発現場、コードレビューの現場でどのようなコミュニケーションをとればよいのかということを紹介します。 コードレビュー 一般企業では外部に提出する書
大きめのこととか,自信のないところを触るときは,コード書く前に,こういう作戦考えてみたけどどうですかって聞いてみたり,こういうことやりたいんだけど一緒に考えませんかって,いっしょに話して設計考えたりするとよいと思う. 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので,未然に変な設計のままコード書いてしまうのを防げる. 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「(こんな実装は)有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う.我が社にはそんな強い言葉でレビュー書く人はいない. 我が社には,普段から強い言葉を発する人もいなくて,みんな物腰柔らかな変な言葉を話している. 言葉使いや文体は,ずっと過ごしてると同僚から移ったりするので,普段からそういう言葉を話していると,全体の雰囲気も悪くなりそ
コードレビューをする際と、してもらう際に気をつけるべきだと思っているをまとめておきます。 レビュイーとして大切なこと コードレビューをお願いする前に レビュアーが高いパフォーマンスを発揮するためには、レビューを受ける人の心構えと事前の打ち合わせが実は最も大切です。 特に大きめの変更のコードレビューをお願いする前にすると良いこととしては、 まず、レビュアーを確保する そのレビュアーと大まかな設計の合意をとる という方針でやっていくのが良いです。 レビューしていても、根本をひっくり返すような指摘はしにくいですし、したとしても、それなら1から書いたほうがはやくて良い物が出来るといったことが簡単に起きます。 「レビュー後に直せるもの < レビュー前に直せるもの」 ということを意識して、Issueなどを用いて、出来る限り事前に設計、打ち合わせをしましょう。そうすればレビュアーもすんなりレビューできる
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための7つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
トランザクションはACID特性を満たすと言われている。 そのうちA(Atomicity)はトランザクション内の操作をAll or Nothingとなるよう保証し、トランザクションが中途半端に実行されて(アプリケーションレベルから見た)データの整合性が失われることを防ぐ特性。またD(Durability)とはシステム運用中に起こる様々な障害からデータを守る(整合性を保つ)特性。 これらの特性を満たすためのDBMSの古典的なテクニックがすごく面白いので、それに関するMySQL(主にInnoDB)のパラメータ・パフォーマンスにどのような影響を及ぼすかを調べた(*'ω'*) なお紹介している技術は基本的に教科書に書かれていた技術で、実際にInnoDBに実装されているアルゴリズムとは異なることがある(とはいえベースにはなっている) 参考 障害の種類 DBMSの基本構成 データベースバッファ 概要 関
去年くらいからよく見かけるようになったスクロールすると、カーテンを持ち上げるように次々にコンテンツが表示されるテクニックをスタイルシートのみ版とスクリプト併用パワーアップ版の二つを紹介します。 まずは、スタイルシートのみ版から。 Fixed image backgrounds スクロールするとヘッダは固定表示で、画像を配置した背景がカーテンを持ち上げるように次のコンテンツが表示されます。 背景は写真も面白いですが、ソリッドなカラーでも面白い効果が得られますね。 Fixed image backgroundsをスクロール 実装はシンプルです、ポートフォリオなどでよく見かけるテクニックです。 Demo 1のHTML HTMLの基本構造は、header要素があり、各スライドはsection要素です。section内には見出しやテキストや画像などを自由に配置できます。 <header> <a hr
和洋風KAIは、Apple・水樹奈々・食べ歩きが三本柱のブログです。モットーは「楽しく」「便利で」「端的に」。 ⇒ アバウト ⇒ 免責事項 1.テキストのみコピペする方法。 リッチテキストエディタなどを使っていると、ブラウザからテキストをコピペした場合、画像なども付いてくる場合があります。 そんな時は「Control+Shift+V(Macだとcommand + shift + V)」を使ってペーストすると、テキストのみ貼り付けることが出来ます。 2.最後に閉じたタブを復活させる方法。 誤ってタブを閉じてしまった時は、「Control+Shift+T(Macだとcommand+shift+T)」とショートカットキーを叩くと復活させることが出来ます。 3. タブにマウスを置くと、ウェブページのタイトルの全てが読める。 Google Chromeはタブを開きすぎるとタブがとても小さくなってタイ
アメリカで大ベストセラーとなった書籍「The Digital Photography」が日本語に翻訳されて発売された。この「デジタルフォト達人への道」(発行:ピアソン桐原)、著者は全米Photoshopプロフェッショナル協会(NAPP)会長のスコット・ケルビー氏、日本語版の監修は日本におけるデジタルフォトの第一人者・早川廣行氏だ。Shuffle読者のために、第1巻から第3巻まで各巻のハイライトを特別公開する。 ピントのしっかり合った鮮明でシャープな写真を撮ることが、プロの写真家にとっては何より重要です。「デジタルフォト達人への道」第1巻からは、「第1章 プロが教える本当にシャープな写真の撮り方」を公開します。 スーパーシャープな写真を撮る:ミラーアップ 連載第1回では、少しカメラのブレに集中しすぎてしまったようです。しかし、まさにそれこそがこの章の目的なのです。つまり、シャープでクリアな写
チヤホヤされたり、肩書きを持ったりするとつい偉ぶってしまいがちですが、気を付けたいところですね。 2. 会話では相手に話をさせる 私はラクをしたいので、なるべく自分はしゃべらず、相手に話していただいて、同じギャラなら出番が少ないほうが効率がいいわけで、これを芸能効率説といいます(笑)。 もちろんこれはタモリさん流のジョークでしょうが、タモリさんといえば「いいとも」での「テレフォンショッキング」ですよね。 聞き役に徹することの大切さを誰よりも理解、実践しているでしょう。 実は、「気が合う」と思ってもらえる一番かんたんな方法は、話を聞くこと なのです。 以前紹介したこちらが参考になるかもしれません。 これであなたも好かれる!「聞き上手」になるための5つのポイント しかし「聞く」といってもただ黙っていればよいわけではありませんね。 あいづちをうったり、適切な質問をして、相手に気持ちよく話してもら
5月20日に弊社から刊行された『プロが教えるデジカメ撮影テクニック』(著者はプロカメラマンの三浦健司氏)という書籍を担当した吉田です。鬼のような上司から「Webで宣伝しろ」と言われたのですが、ただの宣伝なんて誰も読んでくれません。上手な写真を撮るにはどうすればよいのか、8回に渡って書籍の内容を紹介することにしました。 第1回のテーマはスイーツです。どうも弊社の社長が「Webで宣伝するならスイーツを題材にしてみたら?」と言ったそうなのですが、私は平社員なので事実かどうかはわかりません。書籍は今日発売なので、よかったらポチっとしてください。 ◆ 吉田:今日はスイーツの撮影について教えてください。 三浦:またキミに似合わないものを撮ろうとしているねえ(笑)。撮ったのを見せてよ。 吉田:これです。 三浦:こりゃひどいねえ……。脂っこい感じがするケーキだな。バタークリームがベタついて胸焼けしそうだし
2010年04月22日 12時00分更新 文● 小林 伸、撮影協力●クラーク記念高校秋葉原ITキャンパス これから夏にかけて、ゴールデンウィークやら夏休みなど、行楽が楽しい季節になってくる。そんな中、「今、コンパクトデジタルカメラ使っているんだけど、画質がイマイチ」と感じている方も多いだろう。 そんな方にはデジタル一眼レフカメラがおススメだ。コンデジよりも撮像素子が大きい分、美しい写真が撮れるし、知識を身につければこだわった撮影も可能だ。 一方で、デジタル一眼レフカメラを持ちながら、機能を十分使いこなせていないユーザーもいる。さすがに筆者の周囲にはいないが……と、思っていたのだが、目の前にいたのである。 ASCII.jpの編集者Hは、2年前にデジタル一眼レフカメラを約20万円で購入。取材には必ずデジタル一眼レフカメラを持参しながら、撮影時は「オート」か「プログラム」しか使っていない、とカミ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く