フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
こんにちは、アプリケーションエンジニアの id:shimobayashi です。 先日はてなでは開発合宿が行われ、私はエンジニアでありつつもその傍らでディレクター業にチャレンジという形で3人のチームに参加しました。 そんな開発合宿の振り返りを通じて、何かチーム開発のヒントになればと思いこの記事を書くことにしました。 なお、この記事ははてなエンジニアアドベントカレンダーの11日目です。 いきなり崩壊 まずはチームビルディングですが、結果からいうと崩壊しかけました。 やることを決めずに3人でチームを結成*1してしまったので事前の準備として、 目標を設定 目標を踏まえて、取り組むテーマを設定 テーマを踏まえて、サービス案を決定 というアプローチでサービス案を決めようとしました。 妥当なサービス案を考え出すことを狙ったアプローチです。 しかし、いよいよサービス案を決定する段階になって「テーマが不適
1億総デジタルともいえる現代。アプリ開発者やプログラマーの需要も、増加の一途をたどる。 目まぐるしく変化する市場に対応するには、当然人材が必要だが、採用しても教育する時間がなかなか確保できないなど、企業側も複雑な事情を抱えていたりする。 問題解決に一歩近づくには、入社したその日から即戦力で仕事ができるシステムが、必要なのかもしれない。 そこで登場したのが、「シラバス」という学習サイト。「マネして学べる」をコンセプトに開発されたプログラミングeラーニングシステムで、HTML/CSS、WordPress、Ruby on Rails、Backbone.js等のwebデザインやwebアプリの開発を、サイト上のコンテンツを通して学べるというものだ。 開発元の経験から生まれたサイト 開発を手がけたのは、東京理科大学の学生によるベンチャー企業、ダラフ。「シラバス」は、彼ら自身の体験から誕生した。 当時、
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
This document provides a summary of various web development topics and resources, including responsive design, Android fragmentation, Google services, Material Design, web components, and more. It discusses principles like universality and accessibility, and recommends actions like focusing on building interfaces in HTML/CSS directly instead of Photoshop. Links are provided to additional articles
クラウド技術の進化や開発ツールの充実などを背景に、Webエンジニアに求められる開発知識は日々更新され、右肩上がりに高度化していっている。常に成長し続けることなしに、エンジニアが理想的なキャリアを描くことはできないと言っていいだろう。 そんな状況下、柔軟に知識と経験を増やしながら伸びていくエンジニアと、そうでないエンジニアとでは何が違うのか。弊誌姉妹サイト『@type』が主催する『エンジニア適職フェア』(東京ドームシティ)でこのほど、優秀なエンジニアを輩出することで名高いIT企業3社の開発トップを招き、「エンジニアが成長する職場の条件とは?」をテーマにトークセッションを開催した。 《登壇者》 ■クックパッド株式会社 執行役 最高技術責任者 舘野祐一氏 ■株式会社はてな 執行役員 サービス開発本部長 大西康裕氏 ■株式会社nanapi 取締役 執行役員 CTO 和田修一氏 エンジニア育成の取り
Webサイト運営の役割って明確に決まっている?Webサイトの目的と目標は何?Webサイトの現状把握できている?目標が達成できる指標をデータ化している?施策のリストアップと優先順位付けできている?施策の設計図とメッセージはドキュメント化されている?※チェックリストの項目をクリックすると、その解説に飛びます。 やることがたくさんあると何から手をつけていいかわからなくなりますよね。まずは、上記のリストアップした6つのチェックポイントで、自分ができていること、できていないことをチェックしてみよう。また、記事末には、チェックリストをまとめた「Web担当者の心得」を掲載していますので、困ったとき、行き詰まったときのガイドブックとして使ってください。 6つのチェックポイントで「ヒト・モノ・カネ」の投資を獲得できるWeb担当者になろう本連載では、運営しているWebサイトの現状を理解して、戦略と推進する組織
はじめに 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログを読んだときに、僕自身もまた不安定労働から、ある程度「これだったら自分できそうだ」という気持ちで取り組み、独習のつもりで幾つものプログラムを書いたりしていた。だから、ニートからプログラマを目指して、社員として今頑張ってます、というのはすごく仲間意識を持ってしまうし、同じように頑張ってほしいという気持ちはある。 確かに、上の記事の趣旨自体、つまり「独習で学ぶことは、実務上でカバーできない部分がある」という側面があることは認めつつ、しかし、自分自身は独習したことが案外実務上で役に立っている部分もあり、その部分は明確にしたほうが、今後同じように独習して、今度プログラマを目指す人々において役に立つのではないか、と思うので、この記事を書こうと思う。 この記事で扱う「Webアプリケーション開発
非デザイナーエンジニア(Rubyist)の私が、一人でこんなWebアプリを作ってみました。 まだβ版ですが、Pocketやfeedlyの未読コンテンツの中から、 重要度が高いものだけをリマインドしてくれるサービス「Reminderr」です。 Reminderr:http://www.reminderr.me/ 要するに、私自身のPocketとかRSSがカオスになっているので、 その中で重要なものだけ教えてほしかったので、 自分で作っちゃえ!って思って作りました。 そのときに使った便利ツールたちをまとめておいたら便利そうだったので、 今回使ったもの+αを全てまとめてみました。 紹介するツールたちを駆使すれば、 非デザイナー&デザインセンス0の私が、 1週間程度でこれくらいのアプリをリリースできるので、 他のエンジニアにも便利なツールがいっぱいあると思います。 Bootstrap系 Boots
休日。何かしなければという焦りがあるんだけど、何をしようか思いつかない。 現在の飯のタネである(僕はいわゆるSIer)システム系の勉強を、最近してないことに気づいてはいるんだけど、インフラの構築に気が行ってしまって、なかなかスタートを切れない(どうせなら借りているVPSに対して色々と自動化して・・・と)。 そこでインフラの部分に気を取られることは無いHerokuを使って、何か作ってみることにした。 >> できあがったもの >> http://studysuggest.herokuapp.com ※後ろの方にも書いてますが、綺麗に何かを作るより、まず動くものを作って公開するというのを主題にしてます。 Herokuとは ざっくりとまとめると 高負荷でなければ無料で利用できる 定期的にバックグラウンドで◯◯動かす みたいな事やると、無料枠超える可能性出てくるので注意 gitにソースを上げて、流し
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
職業高校の技術機能理論的学歴観の変容 - はてな村定点観測所 ウェブサービス開発の現場におけるデザイナー不要論と5〜10年後の生存戦略 - 情報建築家 石橋秀仁 特にWeb、スマートフォン領域のエンジニアやデザイナーにとって(今回はこの領域に限ります)、大学や専門学校、職業高等学校での専門的知識がどれだけ役に立つのかという議論は長く続いているが、なんか齋藤さんと石橋さんという2人の友人がそれぞれ同時に違った深みで議論を始めたので(齋藤さんは階級文化の観点から、石橋さんはデザインを広い活動の中に位置づける観点から)、思ったことを書く。もっとも、現実のソフトウェア開発は厳しいのであるが。 Summary パラグラフ・ライティングを出来る程度に回復していないようで、どうもまとまっていないので、論旨を書きます。 学校でどんな専門的なことを学んでも、デザインを他の活動に広くつなげる能力を持っていても
本稿では、まず「ウェブサービス開発の現場で、ウェブデザイナーの仕事はエンジニアに奪われつつある」という脅威を語る。次に、生存戦略を考えるヒントとして「分かりやすい生存戦略」を2つ提示する。「アートディレクター」と「フルスタックウェブデザイナー」という2つの生存戦略だ。 なお、「仕事を奪われていくプロセス」と「生存戦略を遂行するプロセス」について、5〜10年程度のタイムスパンをイメージしている。 ウェブデザイナーの仕事がエンジニアによって奪われつつある ウェブサービス開発の現場では、ウェブデザイナーの仕事がエンジニア/プログラマーによって少しずつ奪われつつある。とくに小さな組織や新規事業の現場では。 象徴的なのは「Bootstrapがあればデザイナー不要だよね」論。「もはや社員としてデザイナーを雇う必要はなくて、必要な時にランサーズで発注すればいいよね」「スタイルシートいじったり画像パーツ作
2年前に一念発起して組んだマシンがあって、Core i7と32GBものRAMを節操無く積んでいたもののファンの音が気になるとか子供が邪魔をするとか、ディスプレイが小さいとか理由であまり使っていなかった。引越を機会に自分の仕事場がつくれそうなので、これを機会にデスクトップ環境をもう一度整備した。 ディスプレイ やはりこれが一番大切だろう。必須条件は解像度がいわゆる4Kあること。MacBook Proを使ってRetinaの美しさに慣れてしまった今、これまでの普通の液晶モニタでは何インチあっても意味がない。もともと液晶のサイズそのものではなく、解像度に興味があったので必然だ。本当は海のむこうだと$500とかそういうレベルで変えるらしいのだが、日本に住んでいるのでなんか出てるかなーと思ったらASUSからPB287QとIODATAからM4K281XBがそれぞれ出ていた。ぼくは海よりも深い理由からAS
web系スタートアップ開発チームが仕組みもへったくれも無い状態からすったもんだありつつリモートワーカーも交えて良い感じにワークする体制で開発できるようになったなぁと言って良いところまで来たと感じたので、ここらでひとつ段落をつけて開発体制とか組織設計、体制作りみたいなところの話をまとめておきたいと思います。 サービス開発の現場に仕組みや体制を引く目的と意味 まず開発チームに体制や仕組みを引く意味、目的について。 開発速度の向上 これ1点に設定しました。 開発スピードで市場ごと引っ張る 展開中の事業ドメイン(教育)は今、ほっといても急成長中の市場でタブレット端末の導入がどんどん進んでいます。 が、私立やいけいけの公立を除いて大体の公教育の現場では単純に既存のパソコンと置き換えてコスト削減に利用するだけだったり、まだまだ端末の普及が途中です。 IT機器の導入が教員の業務効率化や教育そのものの質の
Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
これはいいサービス!助かりますねー。 Picky-Pics(ピッキーピックス) チラシを簡単に作れてしまう 「Picky-Pics(ピッキーピックス)」はチラシや名刺をウェブ上でサクサク作れるウェブサービス。これさえあれば、Photoshopは要りません。デザインセンスも要りません。すばらしい! 使い方は簡単。作りたい資料を選択して、デザインを選びます。 すると編集画面に移動します。あとは文字や背景を加工していくだけ。 素材は5万点近く用意されているそうです。 直感的に素材を追加できます。 各素材はドラッグすると移動します。簡単! 編集画面の使い勝手もすばらしく、ピクセル数を合わせやすいガイド機能が実装されています。 フォントも豊富!これは嬉しいですねー。 出力は3パターン。ウェブページにもできるというのは嬉しいですね。 有料素材を使っている場合は、出力にあたって費用が発生します。この値段
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く