サービスを提供するにあたって取得されたくないアカウント名が集まっているライブラリが欲しいんですけど〜みたいな時 - その手の平は尻もつかめるさ
例えば `logout` みたいなユーザ名を取得されてしまうと，ユーザ側からすると不気味に見えるし，URL設計が終了している時などに脆弱性になり得る (とは言うものの，そもそもそういった脆弱性は根本的に防ぐべきだし，URL設計を終了させてはならない)． ので，タイトルのようなことをpostしたら知見がモリモリ集まってきた．ありがとうございます． 取得させたくないアカウント名を集めてあるライブラリ欲しい気がする．authとかlogoutとかdataとか……— アドセンスクリックお願いします太郎 (@moznion) 2017年4月10日 @moznion 所得させたくないアカウント名リストならこういうレポジトリがあります https://t.co/uyYJxaFbrX— kosuge (@9m) 2017年4月10日 @moznion このリストに追加で日本向けに regist っていうアカ
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
そして物語は何度目かのアプリ内通知再実装を迎える - その手の平は尻もつかめるさ
というタイトルでKyoto.なんか #2で発表してきました． そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています． Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？ という思いがあり，そこら辺アプリ内通知周辺の技
ページャNight 1ページ目という勉強会やりました - その手の平は尻もつかめるさ
そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
