捜査関係事項照会の実務について俺が見てきたこと - Diary
捜査関係事項照会の実務について俺が見てきたこと 俺はどういう人間か: 法律関係のことはあまり知らない(弁護士とキャバクラの値段が同じということぐらいは知っている)。ネトゲや Web サービスの開発を 10 年以上やっている。大量の個人情報を取り扱い金銭化するようなサービスの開発、運営に従事したことはない。高等教育の類いはいっさいうけていない。 警察の捜査関係事項照会について、俺がこれまで見てきた会社ではだいたい管理部門かカスタマーサポート部門が対応していた。法務兼 CS みたいな人もみたことがある。俺がみたものだと、 URL やスクリーンショットをそえて、この投稿者の IP アドレスやホスト名をよこせみたいなかんじであることが多かった。だいたいそれを見れば警察がどういう捜査をしているのかは分かることが多かった。あきらかに不当な照会だなと感じられるものはこれまで見たことがない。 捜査関係事項
プログラミングが出来る - Diary
プログラミングが出来る と一言で言ってしまうのはあまりよくなくて、ある程度分割して考えるほうがいいと思っている。 自分が必要なものを作ることができる みんながもっている共通の課題のうち、自分の技術力で解決可能なものを見つけて、解決するプロダクトを作ることができる 同僚と協調しながら製品を作ることができる おおまかにいって「プログラミングが出来る」というのはこの3個のスキルに分割できるのではないかと思っている。そして、これらはそれぞれあまり関係がない。 自分の課題を高速に解決することができるが、それを製品や OSS にまとめてリリースすることは出来ない人 優れた OSS のポートフォリオを持っているが、同僚という立場の人と協調することはあまり得意ではない人 業務としてプログラミングで成果を出してきているが、別に趣味で自分のためになんか作ったりはしてない人 ゲームを自作しているが、別にそれで食
Firebase でバックエンドエンジニアがいらなくなるは正しくない - Diary
Firebase でバックエンドエンジニアがいらなくなるは正しくない と思っている。 用語定義が曖昧だが、「バックエンドエンジニア」という言葉でなんとなく想像されるものとしては、 Rails とか Laravel とかでデータベースに CRUD する Web アプリケーションを書ける人を指すと思う。違いますかね。そんなに違ってないと思うが。 Firebase でこれらの知識をもつ人が不要か?というとある程度の規模、機能を持つアプリを作ろうと思うとこれは必須になる。 Firebase のデータベースは機能が少なく(とはいえ Firestore はわりと「これで十分じゃん」ではあるが)、なにか複雑なことをしようとすると、すぐに Cloud Functions という機能に頼ることになる。 Cloud Functions はようするに Firebase の Lambda + API Gatewa
見てるページを全部保存するという行ない - Diary
見てるページを全部保存するという行ない をもうずっとしていて、以下のような user.js でページを全部保存してます。 // ==UserScript== // @name 見たサイト全部保存 // @namespace http://tampermonkey.net/ // @version 0.1 // @author You // @match http://*/* // @match https://*/* // @grant GM_xmlhttpRequest // @noframes // ==/UserScript== if(!!document.querySelector('title')){ const title = document.querySelector("title").textContent; const url = location.href; GM_x
Firebase 使ってみた 2018 - Diary
Firebase 使ってみた 2018 最近は技術についてはレイトマジョリティでいいなと思ってる。 Firebase はもう完全にやっていけるかんじっぽいのというのを各方面から聞いたので試してみた。 だいぶ前に Firebase を使ってみたとき、 Realtime Database のクセが強すぎてこれはあかんなという感じだった。今では Cloud Firestore があるので話が違うだろうと思いあらためて実用アプリを一個作ってみた。 前にクライアントサイドだけで実行して保存先は Google Drive という野蛮なメモツールを作ったことがあった。これのバックエンドを Google Drive から Firebase にしてみた。 元々のツールが Google Drive との接続部分を一つのファイルに切り出していたので、これをいじって Firebase に対応するだけでスッと作れた
Slack で大きい絵文字を簡単に作る - Diary
Slack で大きい絵文字を簡単に作る という遊びがあります。 こんなん。画像を 4x4 で 16 枚で分割して :yos-1-1::yos-2-1::yos-3-1::yos-4-1: :yos-1-2::yos-2-2::yos-3-2::yos-4-2: :yos-1-3::yos-2-3::yos-3-3::yos-4-3: :yos-1-4::yos-2-4::yos-3-4::yos-4-4: みたいな感じで貼るわけです。 とか 中身としては 16 枚の絵文字なので適当に差し替えて遊んだりできます。 とか。 これを手で作るのはだるいので簡単に作る方法です。 画像の用意についてはこれを読んでください。 そのようにして画像が用意されると、これをアップロードしないといけないのですがこれを手でやるとだるいです。そこで emojipacks という悪魔のツールを使います。 emojipa
Heroku で静的サイト配信 - Diary
Heroku で静的サイト配信 したいみたいなことがたまにあると思うんですけど、 Heroku Container Registry + nginx でやると今は楽ですね。 Heroku で Docker コンテナを動かす場合、 EXPOSE とかはすべて無視されます。 PORT という環境変数経由で公開すべきポート番号がコンテナ側に通報されます。なので _/nginx を使ってあれこれする場合は以下のようにあれこれするとよいかと。 default.conf server { listen ${PORT}; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location =
WordPress で構築してたサイトを Heroku に移行させた - Diary
WordPress で構築してたサイトを Heroku に移行させた 会社のサポートページが WordPress で構築されているのだが、これがよくわからないさくらの VPS にデプロイされていた。 OS が Ubuntu 12.04 でサポート切れ目前なのだが do-release-upgrade するよりは Heroku かなんかに引っ越してしまえばいいと思ったのでそうした。 KUSANAGI for さくらのVPS WordPress.com その他ごまんとある WordPress ホスティングサービス を使うという手もあったんだろうけど、それはそれでめんどうそうだし自分達の運用ノウハウがある Heroku がよかろうという感じで決めた。 移行で実際にやること。 画像を S3 に上げる Heroku に WordPress デプロイ DNS 切り替え まあこれだけなんだが、 1. は
インフラエンジニアのいない会社で働いて 1 年半 - Diary
インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。 本当に自分達でなにもサーバーを管理してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
