フロントエンドを楽にするために
Qiitaを支えたい技術 at 時雨祭
About
- HN: mizchi
- Qiitaの方からきました(入社半年たったらしい)
- Reactオジサンはそろそろ飽きてきた
- Angularに興味が無いのでこっちにきた
Hajime Koto kthjm
View フロントエンドを楽にするために.md
nobuh
/ Web_Hosting_by_GitHub_Pages.md
Last active
March 9, 2020 04:57
github pages を活用した独自ドメインのWebサイトホスティング
View Web_Hosting_by_GitHub_Pages.md
GitHub Pages を使って無料でWebサイトを運営する
自分コンテンツ
最近書いてないけど Wordpress.com にブログは持っていたり、一応GutHubに自分以外のユーザーもいた事があるソフトを公開している。Twitterのツイートもある。限られた自分の時間で発信していることだし、そろそろ自分ドメインで自分のコンテンツをちゃんと集約化したいなと思いました。
でも運用が面倒
普段サーバー関係の仕事をしているので、Wordpress や他の CMS をいれたりするのは出来ると思いますが、今のところ静的なコンテンツのみの想定だし、CMS だと機能が豪華すぎます。またバックアップやセキュリティ対策などレンタルサーバーであってもちゃんと運用するにはそれなりの手間（コスト）がかかります。ここはコストをかけずにもっとコンテンツだけに集中したいとおもうようになりました。
View twoauth.md
OAuth 対応 Twitter クライアント作成メモ
- 前提: OAuth version 1.0a, Twitter API 1.1
OAuth 認証を通じてツイートするのに必要なたった 1 つのこと
リクエストヘッダに Authorization フィールドをセットする
OAuth 認証を通じてツイートするためには、API に対して POST する際、リクエストヘッダに Authorization フィールドを含める必要がある。
View gist:5107120
https://gist.github.com/mala/5062931
の続き。
Twitterの人に色々と問題点は伝えたんだけど、これからOAuthのサーバー書く人や、クライアント書く人が似たような問題を起こさないようにするために、どうすればいいのかについて簡単に書きます。既存の実装真似して作るとうっかりひどい目にあう。
自分は意図的に「Twitterの脆弱性」という表現を使わないように気を使っていて、それはクライアントアプリ側の責任もあるからなのだけれども、安全に実装するための方法がわかりにくかったり誤解を招きやすかったり、Twitterに買収されているTweetDeckにも問題があったりしたので、それはやっぱりTwitter側の責任の比重が大きいとは思う。とはいっても別に責任を追求したかったり◯◯はクソだといったことを言いたいわけではなく、誰が悪いとか言う以前に、複合的な要因によって問題が起きるときには原因を正しく理解する必要があると思う。
そもそも何を担保に安全性を保証しているのか
- サーバー側で秘密の鍵を持っている(それが無いとアクセストークンを取得できない or 使えない)
tatsuro-ueda
/ WindowsでHerokuをセットアップする手順.md
Last active
April 28, 2016 10:11
WindowsでHerokuをセットアップする手順
View WindowsでHerokuをセットアップする手順.md
WindowsでHerokuをセットアップする手順
※数日後にアクセスしたら
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
ではじかれて入れません。なんてこったあああ！
tily
/ scaling_isomorphic_javascript_code.ja.markdown
Last active
May 1, 2023 09:03
サバクラ両方で動く JavaScript の大規模開発を行うために
View scaling_isomorphic_javascript_code.ja.markdown
サバクラ両方で動く JavaScript の大規模開発を行うために
原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.)
考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket term ?) だ。
過去に多くの開発コミュニティが MVC による解決案を提供し、それによってよくあるユースケースにうまく対処し、地位を築くことができた。例をあげるなら、Ruby や Python コミュニティは Rails や Django を作り、MVC アーキテクチャを実現した。