フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
プログラミングの勉強にあたってよく言われるのは、「流行に左右されるような技術の尻を追いかけるよりも、土台となる技術を身につけることが大切」ということです。 例えば、ウェブブラウザで動くJavaScriptを書くときは、流行しているライブラリの書き方を暗記するよりも、 ブラウザがどのようにCSSやHTMLを解釈してスクリーンに文字や絵を描き出していく(レンダリングしていく)のかを理解することが大切です。 さもないと、ライブラリの流行が変わるだけで勉強したスキルが失われてしまいかねません。 データベースでも同じことがいえます。SQLの文法を学ぶことよりも、データベースがどのようにスケジューリングを行い、 どのようにデータを探索していくのかを学ぶほうが、パフォーマンス・チューニングのコツなどもひらめきやすくなるでしょう 1 。 「土台となる技術を身につける」を、もう少しちゃんと言い換えれば、「今
こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今回ははてなで毎週開催している社内技術勉強会で発表した「技術ブログを書くことについて」という発表資料を公開します。 speakerdeck.com 今回の発表をなぜ行ったかというと、もっと気軽に自分のやったことをブログに書くといいのではという考え方を社内に伝えたかったからです。エンジニアをしていると、ブログを書くときは他の人が書いていないことしか書いてはいけない、しかも完璧に書かなければならない、というような気持ちになることもあります。しかし、ブログを書くことで自分の学習をより深め、加速することもできるので、あまり気負いせずにブログを継続して書いて欲しいという思いを発表しました。これがエンジニアのブログに関する正しい考え方と言い張るつもりはなくて、一つのブログに対する考え方として、参考になれば良いなと思います。 発表で
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
みなさんこんにちは。@ryuzeeです。 人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります(こちらを参照)。 今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。 タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階(初期は4段階)で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。 オリエンテーション信頼の醸成ゴールの明確化コミットメント実行ハイパフォーマンスリニューアルこれらのステージは前半上から下に向います(形成段階)が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく(持続段階)につ
PHPカンファレンス関西2016の基調講演です。
綺麗にコミットしてますか?? はじめまして!Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何? Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
はじめに:「僕にもそんな頃があった」 先日、西脇.rb&神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。 この勉強会は出題者(=僕)が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。 参加者の方の中には最近プログラミングを始めた、という人も何人かいました。 そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。 また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか?」みたいな質問を受けたりもしました。 その中で言われたのが、 「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」 「えっ、そんな短い時間で作れるんですか」 といったようなコメントです。 そういったコメントを聞くと、「あー、僕にも
Objective-Cだと今でもマクロを使うことはあります. (ReactiveCocoaなんかも依存していますね.) プロダクトコードで使うのはできたら避けたいマクロですが,ビルド設定によって動作を切り替えたいときとかには結構便利です. しかしながら,Swiftにはマクロは存在しないので,このような手段を使って代替します. Simple Macros いわゆる定数を定義するマクロです. Swiftで定数を定義したいときはletを使うべきです. #define FADE_ANIMATION_DURATION 0.35 このようなマクロによる定数の定義は, let FADE_ANIMATION_DURATION = 0.35 とletを使えば実現できます. マクロに比べ型チェックがされますので圧倒的にセキュアです. 筆者はこの他に定数を定義するのにcomputed propertyをよく利用
ICSE 2016勉強会に参加するために論文リストを確認していたら、40年間のC言語のプラクティスの変遷を追った論文がおもしろかったので紹介する。 対象の論文 論文: The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015 論文中で使われれたデータ: https://github.com/dspinellis/unix-history-repo 要約 過去40年間のUnixのソースコードを分析し、コーディングスタイルの変化を調査した。その結果、以下のことが分かった。 新しい言語機能は価値のあるものならば採用される レジスタ割り当てをコンパイラに任せるようになる スペースをどこにいれるかなどのコードの書き方が統一されていく 分析対象 1972年以降にリリースされた計66個
Facebookログインが必要なiPhoneアプリはたくさんあり、大抵のアプリケーションはFacebookのiPhoneアプリと連携してパスワード入力無しでログインを済ませてくれるのでユーザーとしてはとても楽だ。 だけど、Facebookアプリを使わずに自アプリ内でWebViewを開いて、そこでメールとパスワードを入力しなければいけないフローになっているアプリもそれなりに見かける。 僕の場合は各種サービスのパスワードは管理ツールで自動生成していて覚えていない。Macの場合は管理ツールが常時立ち上がっているのですぐに参照することができるが、iPhoneの場合は、管理アプリを立ちあげる→マスターパスワードを入力→目的のサイトを選択→パスワードをコピー→元のアプリに戻る、という手順を踏まなければならないため、非常に使い勝手が悪い。 というか、Facebookアプリが認証の仕組みを提供しているのに
2016 - 05 - 27 jQuery + Flux という選択肢 JavaScript Front-End こんにちは、 SKAhack です。普段はMERYのWebフロントエンドを主に書いています。 今回はMERYのフロントエンドで採用している jQuery + Flux という構成を紹介してみたいと思います。 なぜReactではなく jQuery か 普通はReact + Fluxで語られることが多いですが、MERYでは JavaScript の ソースコード の大半が jQuery に依存しており、簡単には jQuery を捨てられない状態です。 また、Viewの変更をする2つのライブラリを 共存 させるのも良くないですし、MERYのサービス特性上、現時点で1画面を頻繁に書き換えるような処理は少ないこと、ReactがサポートしていないIE8など古いブラウザもサポートしているとい
技術部のid:gfxです。iOSアプリ開発に欠かせないパッケージ管理ツールといえばCocoaPodsですが、これはPrivate Podsを作って社内ライブラリ専用のSpecs(private Specs)を管理することができます。 ※ 2014/12/22追記 CocoaPods 0.35.0 でpod lintの--only-errorsが廃止されて--allow-warningsになったのでそのように変更しました private SpecsがなくてもGit URLを指定することで社内用podspecを開発・管理することはできますが、private SpecsがあるとURL指定を簡略化したり依存関係の解決が簡単になるというメリットがあります。クックパッドでもすでに十数個のprivate podspecが登録されており、CookpadUIやAPI clientなどはpodspecとしてp
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
目次 問題の根っ子 Web制作の場合 ー インブラウザデザイン(Designing in the Browser) Webアプリ開発の場合 ネイティブアプリの場合 イニシアチブの所在 プログラマーへの指示の出しかた 判断材料を提供する 検索性の高い資料 カラースキーム レスポンシブ対応 インタラクション プラットフォームごとに異なる自然な表現 まとめ アプリ開発においてのフローは、まずデザイナーがデザイン指示書を作成し、プログラマーが、なるべく忠実にそれを再現するように実装していくという順序になることがよくあります。自然で現実的な発想ではあるのですが、実際の開発の過程では、この流れが思っていたほどスムーズにいかないこともあります。そこで、これまでの経験を踏まえて、今後案件をはじめる前にデザイナー、あるいは、プロジェクトマネージャーやディレクターに読んでもらうための資料を作成することにしまし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く