You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Use HTTPS for local development Stay organized with collections Save and categorize content based on your preferences. Most of the time, http://localhost behaves like HTTPS for development purposes. However, there are some special cases, such as custom hostnames or using secure cookies across browsers, where you need to explicitly set up your development site to behave like HTTPS to accurately rep
こんにちは。ハウスマートの高松(@t2kmt)です。 皆さんは開発要件をまとめるのにどんなフォーマットを使っていますか? 開発要件をいい感じにまとめるのって大変ですよね。 ドキュメント整備せずに開発に着手し始めてしまうと手戻り抜け漏れが出てしまいますが、一方で要件定義書をガチガチなフォーマットにするとドキュメントの作成自体の工数が増えてしまいます。 スタートアップはスピードが命。ドキュメントを書きまくって開発が進まないなんて言語道断です。 開発要件の整理はプロジェクトの成否に多大なインパクトを与えますが、ほとんどの現場では企画を考える人にフォーマットが委ねられていることが多いと思います。 今回は皆さんが快適に開発要件をまとめられるように、ハウスマートで利用している mini spec というフォーマットをご紹介します。 mini spec とは mini spec とは開発の要件をまとめる
趣味でも業務でも日々Webサービスを開発しているzaruです。こんにちは。ついにアドベントカレンダーも最終日です。まだサンタとしての仕事が残っています。さて今回は仕事としてWebサービスを開発するときに気をつけたいポイントを紹介します。まぁ仕事に限った話じゃないですが…参考になれば幸いです。特に新卒プログラマあたりに読んでもらえればと思います😀 なお僕の業務上インフラ周りはAWSが多いです。 RASISという指標 RASISという指標があります。コンピュータシステムの評価指標5つの頭文字を取ったものです。 Reliability(信頼性) Availability(可用性) Serviceability(保守性) Integrity(保全性) Security(機密性) 今回はこの5つの指標に沿ってポイントを紹介していきます。RASIS自体については色々なところで解説されていると思うので
追記(宣伝): 今年の夏から大阪でフルリモートなフリーランスAndroid/iOS/Webエンジニアをやっています。ただいま週1-2または請負のお仕事お待ちしております・・! 画面見た人から(Enterやらショートカットやら連打で)何やってんだかわからないって言われることがたまにあるので、Android Studioでどうやってコーディングしているのかを書きました。 単なるショートカット集ではなく、あえてエラーのある状態を作るなどのテクニック集です。 なおMacかつAndroid Studio標準のキーバインドを前提としているので違う方は読み替えてください。(もちろんIntelliJでも同じことができるはずです・・!) 原則 考えるな、感じろ。: Alt+Enterや補完キーなどを押した次の状態を頭の中に思い浮かべながらに対して反射的に操作すると、超高速コーディングできる エラーだろうが汚
A README is one of the first things people see when they find your open source project. It should be helpful, welcoming, and friendly. Posted on 14 March 2016 by Rowan Manning. Tagged with Open-Source, Writing, Documentation 87 responsesSyndicated to Twitter Your project’s README is pretty important; it’s often the first thing that a person new to your project will see, and is frequently the only
「gulpって何だよ、makeでいいじゃん(要約」論争について、私もちょっと一本講釈をぶってみることにする。あれやこれやといった実利的な話をするつもりはない。そういうものは既に書いた人がいるのでそちらを参照のこと。 Gruntの思い出 Gruntは、私の印象で言えば車輪の再発明の失敗作のようなもので、タスク間の依存関係が破滅への一途をたどり管理不能に至るなど、宣言型の負の側面が強く出てしまった。しかし、設定は本当にサンプルコードのコピペだけで組み立てられるので、JSが不得手なデザイナーなどには非常に受けが良かったという点は忘れてはならない。ちょうど、html5ブームが本格化して, Apache Antとかに慣れ親しんだJava(主にSIer)系の人が入ってきたタイミングにあった道具かつ、Yeomanファミリーにも組み込まれており、それでいて簡単な事をやらせるには悪くはない具合のシンプルさ、
http://d.hatena.ne.jp/m-hiyama/20150511/1431306678 の件 最初に 僕もgulpが今後生き残るかというと、かなり懐疑的です。開発パラダイムに合わせて変わっていくで、来年の段階で自分はgulp使えないなといっている可能性は十二分にあります。そのタイミングの一つはES6 import がHTTP2で並列ロードのオーバーヘッド無しで解決されるようになるタイミングでしょう。 根本的な問題として、Web周りは標準化の関係で動きが遅いです。最新の仕様ではままならず、ブラウザ間の実装がまちまちで、また開発上の要求が多様なのでプリプロセッサで解決する文化が根付きました。プリプロセッサがいらなくなるぐらい個々の標準が洗練されればプリプロセッサも不要になりますが、そのような未来は、今の動きをみるに、あと15年は来ないように思えます。 とはいえ、ただひとつ言えるの
TypeScriptでは、コンパイルが必要です。プログラムをブラウザーとNode.jsの両方で使おうとすると、さらに加工が必要です。ミニファイだの文書も作るだのすると、ちょっとしたビルドプロセスとなるので手作業では辛くなります。 今更Makeでもないよなー、と思い、最近のビルドツールを試してみました。 内容: 流行りすたりが激しすぎる gulpを使ってみる:こんなサンプル gulpのビルドスクリプト タスクランナーってのはビルドツールとは違うのか? ビルドツールは進化したのか 参考資料: 例題のファイルとコマンドの一覧 ソースファイル 追加の話: gulp問題ひきずり:ウォッチがまたおバカ過ぎる 流行りすたりが激しすぎる 「確かGruntってツールがあったよな」と、インストールと使い方を調べていると、やたらにgulpって単語が目立つんですよね。Gruntのライバルの新興勢力らしいです。 「
先人たちが1年前に通った道で、いろいろいまさらかよって話なんですが。基本的に以下の記事読んだら分かります。要はGulpとかGruntといったモノ使わずにnpm run hogehogeでビルドしよーぜって話です。 task automation with npm run オレ的Gruntに対する最新の気持ち - from scratch Node - npm で依存もタスクも一元化する How to Use npm as a Build Tool // package.json "scripts": { "start": "npm run start-serve & npm run watch", "test": "stylestats public/files/css/maple.css", "start-serve": "browser-sync start --server publ
http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
SHIMIZU Taku @takuan_osho チーム開発のベストプラクティスは議論されているけど個人開発のベストプラクティスは共有されてないからそういうことを議論するのやりたいね、ということらしい。 #mydev
個人開発を支える技術Night オープニングトークでも話しましたが、第一回だけで終わらせる気はないので第二回以降の開催場所を提供して下さる方や、参加したい方は @nekova_ までメッセージを頂けると嬉しいです。 @nekova 個人開発を支える技術 オープニングトーク @otiai10 個人開発と徳 @KAZZONE Animetick on さくら VPS @deeeki フィリピンでつくったもの @9m ツイセーブを支える技術 ほか @soramugi 同棲生活における個人開発時の問題 @kyo_ago 話すことと作ること @k2nr_ DokkaaでドッカドッカDocker @mizchi 骸骨駆動設計 @Linda_pp 草を生やす技術 @azu_re Githubで書く電子書籍 @h_demon @kjirou エタらないための技術力
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
こんにちは、岡崎 @watermintです。 このエントリは GREE Advent Calendar 2013の記事です。この記事は5日目の記事です。 今日はGREE Tech Talk #04 スマートフォン時代のソフトウエアテストが弊社セミナールームで行われます。岡崎は「Jenkinsによるテスト自動化の会社への導入」というパネルディスカッションに参加させていただきます。パネルディスカッションの内容がどうなるかは会場の皆様からのご質問などによって変わっていくと思いますが、今日の記事では開発ワークフローについての考えを紹介します。 開発プロセスをなぜ変えるのか 開発プロセスを変えようとするモチベーションはいくつかあると思います。組織規模、ビジネスモデルなどによって多少諸条件は違うとしても大まかには次のような目標を達成することがモチベーションになるでしょう。 開発メンバーが変わっても対応
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く