Go in Go
Go in Go Gopherfest 26 May 2015 Rob Pike Google Go in Go As of the 1.5 release of Go, the entire system is now written in Go. (And a little assembler.) C is gone. Side note: gccgo is still going strong. This talk is about the original compiler, gc. 2 Why was it in C? Bootstrapping. (Also Go was not intended primarily as a compiler implementation language.) 3 Why move the compiler to Go? Not for va
シンプルなKeynoteのテーマ作った - ぴよぴよ.py
研究発表等で使っているシンプルな自作テンプレートをGithubにアップしたので紹介しようと思います。 テーマ 「Mint Green」 ミントグリーンがベースのシンプルなテーマ。 タイトルにはスマートフォントUIというフォントを利用していますが、これを入れてなくても問題なく使えると思います。 テーマ 「Violet」 紫がベースのシンプルなテーマ。Mint Greenの色違い。 こちらも、タイトルにはスマートフォントUIというフォントを利用していますが、これを入れてなくても問題なく使えると思います。 テーマ 「Scarlet」 赤がベースのテーマ。 フォントはヒラギノ角ゴ + Avenir Next。 こちらからDLできます リポジトリ: GitHub - cocodrips/keynote-themes: Free Keynote templates. 良かったら自由にDLして使ってくだ
クラスの「継承」より「合成」がよい理由とは？ゲーム開発におけるコードのフレキシビリティと可読性の向上 | POSTD
コード構造における重要な問題として、複数のクラスを共有する場合に合成と継承のどちらを用いるかという点があります。“has a”の関係と、“is a”の関係と言われる2つの対比です。例えば、“ソファには綿が入っている”と、“ソファは家具である”という違いのようなものです。この例では2つの違いは非常に明白ですが、実際には、“has a”の関係でも“is a”の関係でも意味を成すケースがたくさんあります。ゲームのキャラクターについて、これはコリジョンボックスを持っているかと聞くのと、これは衝突可能なオブジェクトかと聞くような場合です。この2つは全く同じことではありませんが、それぞれが（または両方一緒に）衝突を処理する主構造として用いられ、どちらの方がよいかは必ずしも明白ではありません。私の経験では、直感的には継承の方がよいと思うことも多いのですが、それだと問題がたくさんあって結局は合成の方がよか
Goにatexitやグローバルなデストラクタがない理由 - Qiita
CやC++ではatexit関数で関数を登録しておくと、プログラムの終了時にその関数を自動的に走らせることができる。そういう機能はRubyやPythonにもある。 Goにはそういう機能はない。実装を忘れているのではなくて、意図的にそういう機能を持たせていないのだ。これについてIan Lance Taylorさんが大変説得力のある説明をしていた。 まず第一に、どんなプログラムでも任意の箇所でクラッシュしうるし、まったくバグのないプログラムでもいきなりkillで殺されたりマシンが電源断で落ちるということがある。従ってどんなプログラムも、突然終了させられたあとに、もう一度きちんと動くことができなければならない。つまりatexitはきれいに終了するための機能ということで、atexitが呼び出されないとうまく動かないプログラムというのはそもそも間違っているということになる。 大きなC++プログラムでは
RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
コマンドラインツールを作るときに参考にしている資料 | SOTA
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
よいデザインチームのつくり方 - ワザノバ | wazanova
http://joshuasortino.com/journal/how-to-hire-a-designer-and-build-a-design-team 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 DisqusやTeespringのデザインチームの立上げを指揮してきたJoshua Sortinoが、デザイナーの採用とチームづくりのポイントについてまとめています。「よいプロダクトを生み出す組織づくり」という意味では、他のポジションに共通する話しもあって興味深いです。 採用全般についてのアドバイス サービスづくりに情熱を燃やす人がベストな社員になる。正しいマインドセットがあれば、スキルは追いつく。 問題解決指向が強いが特定のスキルが弱い人の方が、そのスキルはあるが問題を解決しようというマインドセッ
Basics of UX | Articles | web.dev
Basics of UX Stay organized with collections Save and categorize content based on your preferences. This article introduces a workflow that can help teams, products, startups and companies create a robust and meaningful process for developing a better user experience for their customers. You could use different parts of the process separately but they ideally work best as a series of steps. This g
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
X to Close
X’s are everywhere in user interface (UI) design. A powerful symbol, [x] is capable of closing windows and popups, toolbars and tabs and anything else that might otherwise be cluttering up your screen. Twitter XClicking on [x] to close a feature has become an instinctual part of using a computer and a standard in web and software design. Although it may seem like the ubiquitous [x] has always been
エンジニア向けデザインメンター（謎）をはじめて、2〜3ヶ月が経ちました
design_menter.md エンジニア向けデザインメンター（謎）をはじめて、2〜3ヶ月が経ちました @ken_c_lo in 町田の部屋 新年会 2014-03-30 何やるの？ 実際のプロジェクトに入って、エンジニアのデザイン業を支援する デザインといっても広義。（案件のフェーズや人によってそれぞれ違うことやってる） HTML CSS ビジュアルデザイン UI設計 仕様設計 ユーザーフローの設計 プロジェクトの価値の定義、コンセプトメイキング コンサルティング 等… 「考え方から伝える」というのを大切にして、気をつけてる 週1MTG 2時間前後 受託案件の場合、お客さんも含めMTG 宿題で次週の話すテーマを用意してくる MTG以外は、GitHub Issueでやりとり 基本、コーディングはしない けど、エンジニアが書いたSassとかマークアップとか直してプルリクエストすることはある
Modern JavaScript Applications: Design Patterns
It's presented how classical OOP approaches and design patterns can be used for modern JavaScript applications.
Go言語での構造体実装パターン
Go言語での構造体実装は、埋込や独自コンセプトのインターフェースといったGo言語独自の機能を理解して行う必要があります。 今年からGo言語を始めましたが理解が曖昧なままだと実装に迷うことが何度かありました。今回よい機会なので、Go言語での構造体実装パターンとしてまとめてみることにしました。 構造体実装パターン 実装パターンの洗い出しとして、GoFデザインパターンをGo言語で実装する手法をとりました。 その中で繰り返し現れる実装をGo言語での構造体実装パターンとしてまとめてみました。 コンストラクタ関数 エクスポートによるアクセス許可 インターフェースによるポリモフィズム 構造体によるポリモフィズム 構造体によるサブクラス・レスポンシビリティ 構造体による移譲 関数による移譲 以下、それぞれのパターンを解説していきます。 コンストラクタ関数 Go言語には構造体のコンストラクタがないため、構造
Contractual - Design by contract for JavaScript.
Unobtrusive, backwards compatible syntactic sugar for Design by contract in JavaScript. What? Design by contract is a very powerful technique for writing robust software, it can be thought of as a formal but convenient method for specifying assertions. Instead of the developer documenting their assumptions in comments, or worse, not documenting them at all, DbyC gives them a way to express their a
Responsive Design Testing
Responsive Web Design Testing Tool This tool has been built to help with testing your responsive websites while you design and build them. You can enter your website's URL into the address bar at the top of this page (not your browser's address bar) to test a specific page. Unfortunately, with the way browser security works, you are unable to navigate your site through the frames that your website
ゲーム系UIデザイナーの勉強を２年近くやって思った12のこと。 - meycoのUX&UIデザイン技術メモ
あけましておめでとうございます。 新年になり、すこしゆったりとした時間を過ごす事ができました。せっかくなので、去年からずっと思っていたUIデザイナーについて思った頭の中のことをまとめたいと思います。 WEBのUI設計よりも、明らかにゲームの方が難しい これは結構何度も言ってますが、ゲームの設計(ゲーミフィケーションのアプリ含む)の方が明らかに「やることが多い」です。 もっとプレイしてもらうには？ゲームが終わったときに、どのような設計になればもう一度やってくれる？ チュートリアルは必要？やりこみ要素はどうする？ソーシャルとどうやって連携する？ポイント加算の条件は？アクショナブルフィードバックは？日常で使ってくれるような設計には何が必要？盛り込みすぎではないか？ などなど、考えることが多いです。 このあたりは、ソーシャルゲームが本当に上手にできてるなーと思っているので、日々勉強しています。 ゲ
少ない装飾で素材の魅力を生かす、ズルいWebサービスデザイン実践編 // Speaker Deck
WCAF Vol.11 「Design」 in 福井 で発表させていただきました。 http://wcaf.doorkeeper.jp/events/7028 協力： we love heroku by @ppworks http://welove.herokuapp.com/ （参考）ppworks 氏によるエントリー http://www.genuineblue.jp/posts/weloveheroku-design-renewal/ ズルいデザインテクニック2013 + セミフラット version - in 福井 https://speakerdeck.com/ken_c_lo/zuruidezaintekunituku2013-plus-semihuratuto-version-in-fu-jing
Web API Design
Web API Design Crafting Interfaces that Developers Love Brian Mulloy 2 Table of Contents Web API Design - Crafting Interfaces that Developers Love Introduction............................................................................................................................................ 3 Nouns are good; verbs are bad....................................................................
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Design
イマドキCSS設計
