俺が考える最強の新規サービス開発フロー - 小さなお城
インターネットサービスを想定した理想を書いてます。 エンジニアリングに特化した話ではなく、アイディアを思いついてからリリースするくらいまでの浅く広い話で、個人的な趣向であり、組織や環境によっては合わないかもしれません。 とりあえず、リーン・スタートアップとアジャイルサムライ−達人開発者への道−は、すごくいい本で勉強させていただきました。 アイディアを整理します 実現したいアイディアが解決するユーザプロブレム、提供する価値を整理します。 例えば、 ● ユーザプロブレム: お腹いっぱい美味しいものを食べたい！ ● 提供する価値 : 安くて美味しくて腹持ち良い食べ物屋さん アイディアの簡単なペルソナを想像します ペルソナとは提供するサービスの一番の顧客になってくれる人の人物像です。 例えば、 G太、小学1年生男児。体重40kg。 頭はおにぎりのような形をしており、10円ハゲがある。 小学校では
angularJS と jQuery に関する誤解を解く - nazokingのブログ
最近 angularJS に対する期待の低下が著しくてつらい。 なんだかんだで SPA から jQuery に戻った話 - ボクココ Angularの問題では はてなブックマーク - mizchi のブックマーク - 2015年5月18日 みんな使いどころを間違ってるんや。１年半くらい使ってて不満もあるけど自分のよく使う範囲では angularJS 最強だと思う。 angularJS が向いてるのは Single Page Application ではない angularJS が向いてるのは ◎ フォームのような細かい部品を多用 ＆ DOMツリーとデータスコープがほぼ一致していてユーザの入力をサーバに送ったりする webアプリ。管理画面、マイページ、業務アプリなど △ Single Page Application ← 簡単に作れるけどページ間の連携が必要ないならサーバ側で分けてしまった方
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
CSSで泥沼にはまらない3つのアプローチ｜『プロとして恥ずかしくない 新・WEBデザインの大原則』発売記念イベント
注釈 60分のセミナー用のスライドです 60分間ひたすらしゃべるための資料なので、目次はありません セミナーのフォローアップのために公開しています 文字が大きいのは、会場の後ろの席でも見えるようにするためです Cascading Style Sheets .header { margin: 8px; color: #f00; } マジックナンバーの良くない例 .main { float: left; width: 640px; } .main h1 { width: 640px; } .main p { width: 640px; } .main ul li { width: 620px; margin-left: 20px; } 数値が乱立 .aaa { width: 640px; } .bbb { width: 324px; } .ccc { width: 216px; } .ddd
「動いているからいい」では済まされない技術的負債と使われ続ける枯れた技術。 | srockstyle
@srockstyleです。 最近あちこちで技術的負債と枯れた技術の話があがったりしてるみたいですけど、個人的には技術的負債と枯れた技術には厳しくあたらなきゃなあと思ってます。 枯れたソフトウェアっていう名目で古いソフトウェアを使い続ける現場多いんですけども、意外とびっくりするようなバグがあったりすること、最近多い気がしてます。bashしかり、OpenSSLしかり、glibc……まあ、別になれたもの使えばいいと思いますが、かといって「すでに動いているから変更の必要がない」という考え方って僕自身としては危険だなと思ってます。 セキュリティパッチを当てる事に対してすごくネガティブなイメージもたれる人っているんですけど、サーバサイドといってもOSレイヤーのソフトウェアの説明って説明してもわからないひとからすると優先順位は低いです。そしてOSレイヤーの話をしても緊急度がぴんとこないと結局そこにパッ
タグ機能を実現するための便利なデータベース設計を３つ紹介 | colori
AND検索 「CSS+HTML+JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LIKE "%HTML%" AND tags LIKE "%JavaScript%" OR検索 「CSS|HTML|JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" OR tags LIKE "%HTML%" OR tags LIKE "%JavaScript%" 引き算検索 「CSS+HTML-JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LI
状態遷移図／表、すなわち設計をコードでテストする
状態遷移表からひな型コードを生成する この状態遷移表からコードを起こすわけですが、状態遷移の実装については『StateパターンでCSVを読む』を書きました。デザイン・パターンの一つ:Stateによる実装です。今回の実装はC、継承も仮想関数も使えないという利き腕を封じられた条件なので戦術を大きく変えにゃならんです。 状態遷移の実装は要するに「（1）現状態 と （2）受理したイベント の組」に対応する「（3）アクション と （4）遷移先（新たな状態）」を引き当てることに他なりません。ならば上記（1）～（4）の並びをレコードとし、そのレコード列（＝状態遷移表）から「（1）現状態 と （2）受理したイベント の組」に一致するレコードを探し出して「（3）アクション を実行して （4）新たな状態 に遷移」すればいい。 状態遷移表からひな型コードの生成には使い慣れた「T4-template」を用います。
I am mitsuruog | 進化の早いフロントエンドの世界についていくために、スタイルガイドを有効活用しているという話
フロントエンドの世界では、日々新しいフレームワークやライブラリが生まれています。 初めてそういった新しいものを習得する場合に、なるべくなら近道したいと思うのが人の気持ちだと思います。 まず大変なのが、Hello World から実際のプロダクトやプロトタイプで利用する場合で、これは初めてで何もわからない土地を一人で散策するような感覚にも似ています。 今日、紹介するのは私が進化の早いフロントエンドの世界で、より早く未開の土地に慣れるためにスタイルガイドを有効活用しているという話です。 ちなみにこの記事はFrontrend Advent Calendar 2014 - Qiitaの 6 日目の記事です。 5 日目はじめての CSS 設計 - Qiita(@moschann) 7 日目CSS のプリプロセスとポストプロセス、そして Rework と PostCSS(@morishitter) 良
オレ流AngularJSを使った設計ポリシー
Chrome MySQL Adminでは、 AngularJSを使って実装を行っています。Chrome appsでは、 何らかのMVC Frameworkの利用が勧められています。 AngularJSは、Controller、Directive、Template、Serviceなど、いくつかの部品群を組み合わせてアプリケーションを構成することになります。その機能の豊富さ故に、実はちゃんとしたポリシーを決めておかないと、いかようにでも作れてしまうために、かえって複雑さが増してしまうという危険性も出てきます。もちろんアプリケーションの作り始めは試行錯誤の連続なのですが、徐々に自分なりのポリシーみたいなものが確立されてくるはずです。 本エントリでは、Chrome MySQL Adminでの設計/実装ポリシーを簡単に紹介してみたいと思います。ちなみに、全てのソースコードは、以下にあります。 htt
長期かつ修正頻度の高いPJでのCSSメンテ - ワザノバ | wazanova
http://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 長期的な大規模プロジェクト、かつ修正頻度が高い場合は、DRYよりはメンテ性を最優先にしたCSSを書くべきという、Ben Frainの方法論です。長文ですが、よくまとまってると思います。 1) テクノロジーとツール プレプロセッサ 長期のプロジェクトにおいて重要なのは、テクノロジーではなく、何ができて、どう進めるかというアプローチ。 Sass / LESS / Stylus / Myth などどれでも、しっかり書かれていれば、必要なときにいつでも統合はできる。プレプロセッサは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）