サービスを提供するにあたって取得されたくないアカウント名が集まっているライブラリが欲しいんですけど〜みたいな時 - その手の平は尻もつかめるさ
例えば `logout` みたいなユーザ名を取得されてしまうと，ユーザ側からすると不気味に見えるし，URL設計が終了している時などに脆弱性になり得る (とは言うものの，そもそもそういった脆弱性は根本的に防ぐべきだし，URL設計を終了させてはならない)． ので，タイトルのようなことをpostしたら知見がモリモリ集まってきた．ありがとうございます． 取得させたくないアカウント名を集めてあるライブラリ欲しい気がする．authとかlogoutとかdataとか……— アドセンスクリックお願いします太郎 (@moznion) 2017年4月10日 @moznion 所得させたくないアカウント名リストならこういうレポジトリがあります https://t.co/uyYJxaFbrX— kosuge (@9m) 2017年4月10日 @moznion このリストに追加で日本向けに regist っていうアカ
最近の社内Wikiの書き出し - その手の平は尻もつかめるさ
最近，社内Wiki書く時にその記事の頭に「この記事で分かること」というセクションを持ってくるようにしている．こんな感じ． wikiのページを開いた時に真っ先に「どういう情報が得られるか」が書いてあると，取捨選択を早い段階から行えるので調べ物のスピードが上がって良いような気がしている． あと所属している組織ではConfluenceを使っていて，Confluenceの検索機能に引っかかるような (引っかけやすいような) ワードを「この記事で分かること」に含めるように心がけている． 地味に便利になりつつある気がしている． [追記] そう言えばConfluenceの検索結果は「タイトル」と「サマリ」が出るんだけど，冒頭にこういう情報を書いておくとそれがサマリ部分に表示されるから，検索結果一覧の段階から情報の取捨選択できて便利というのもあった．
そして物語は何度目かのアプリ内通知再実装を迎える - その手の平は尻もつかめるさ
というタイトルでKyoto.なんか #2で発表してきました． そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています． Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？ という思いがあり，そこら辺アプリ内通知周辺の技
情報共有システム (Wiki みたいなやつ) に求めること - その手の平は尻もつかめるさ
いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて，気に食わないところを twitter にガーッと書いたんだけど，さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので，僕の思う情報共有システムに求めることをここでまとめておくことにする． エディタが腐ってない これは本当に重要で，エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし，起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある．さもなくば Wiki は廃墟と化す． WYSIWYG なエディタを利用するのは難しいと思っていて，本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) の
Java でテストカバレッジを取る (JaCoCo編) - その手の平は尻もつかめるさ
一種の指標になるので，なんだかんだでテストカバレッジは取りたくなります． Javaでそれをどうやるかをサッと検索すると，Coberturaを使う方法とJaCoCoを使う方法が引っかかると思うんですが，Coberturaの方はJava8のコードが含まれているとJavaNCSSの兼ね合いで発狂して使えなくなったり，Mavenのtestライフサイクルにfindbugsやcheckstyleを含めると使えなくなったりと色々不便なので，JaCoCoを使う方法でやることになっていきます． Mavenでどうやるかというと，pom.xmlに <plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.7.4.201502262128</version> <executions>
テストにコケる度にシーザーが死ぬ仕組みを作りました - その手の平は尻もつかめるさ
タイトルは釣りです。 App::WithSound をリリース致しました。 https://github.com/moznion/App--WithSound https://metacpan.org/module/MOZNION/App-WithSound-v1.0.2/with-sound (2013.03.06 追記) App::WithSound はv1.1.0 にバージョンアップしました。 コマンドの成功・失敗時だけでなく、コマンドの実行中にも音声を再生出来るようになっています。 https://metacpan.org/module/MOZNION/App-WithSound-v1.1.0/with-sound (追記ここまで) App::WithSound? コマンドが成功するか失敗するかによって、その結果に対応した音声が流れるアプリケーションです。 まず、このモジュールはm
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ
そこそこ前に書いた記事が炎上してて、軽く恐怖と困惑を抱いております、moznionです。 おいおい身バレすんじゃねーか、これ！！！！！！ さておき、本記事は 米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ の補足です。 個人的には YAPC::Asia Tokyo 2012 にてLT-THON なるイベントが開催されるようです - その手の平は尻もつかめるさ の方もお願いしたい所存です！！！ げんぶん 要求が来ていたので原文を載せます。 さあ、これで僕の危うい英語力と妖しい日本語力によって生成された 「盛った意訳」*1や「曲訳」や「誤訳」(←コレが一番ヤバい)が浮き彫りになるって寸法ですよ！！ 以下引用 Hi, When making any additions or changes to source code anywhere in the ou
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
