本稿は Swift Tweets 2017 Summer で発表（ツイート）したものをまとめ、Qiita 用に追記・再構成1したものです。 発表概要 CotEditor プロジェクトの現主催者 1024jp です。CotEditor は昨年 2016 年に Objective-C から Swift に移行しました。今日はその話をします。 本発表は、事前に以下のような概要を開示していました。 2004 年から脈々と受け継がれる総 Cocoa 製の macOS 用テキストエディタ CotEditor は、昨年 2016 年に Objective-C から Swift に 100% 移行しました。 Swift は魅力的な言語ですが、すでに Objective-C で 10 年超動いてるアプリケーションを誰に頼まれたわけでもないのにわざわざ Swift で書き直す意味は果たしてあるのでしょうか？
2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
個人の意見 aka ポエムです。 界隈的には今さら感がすごいけど。 そんな今さらポエった事情としては、 とある案件でSPAをReactで作りつつサーバーサイドレンダリング（以下SSR）をすることになるかも SPAじゃないページもまとめてReactでSSRすることになるかも ただ個人的にはSPA+SSR不要論者 サーバーサイドのテンプレートとしてのReactも冗長なだけやろ派 でも仕事なのでしゃーない（お客様がそう申されるなら・・ なのでやるからには再考察してみて、前向きにやれる要素を見つけたい！ けどどんだけ考えてもやっぱり意義が見つけられなーい( ´Д｀)=3 という感じで、SSR自体の是非はまあどうでもよくて、ただ個人的に「しなくていい」と思ってる気持ちをまとめたものです。 技術に是も非もないです。大事なのはどう使うかなのです。 ちなみにやってみた結果・・とかいう話ではなく、やってない
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
