著者:takahashi
GitHub、Microsoftに買収される
以前からちらほら噂がでていたMicrosoftによるGitHubの買収ですが、ついに現実のものとなりそうです。
Microsoft、GitHubを買収か──Bloomberg報道 – ITMedia
Microsoft、GitHubを買収か？ – Tech Crunch
マイクロソフトがGitHubを買収か、交渉が再開したとの報道 – THE BRIDGE
GitHubはソースコードの分散バージョン管理システムである”Git”をベースに、成果物に対する不具合報告や議論をする機能(Issue)、Gitプロジェクトのフォークなど、多くの人でソフトウェアなどを開発・共有していくのに必要な機能を提供する高機能な開発者コミュニティサービスです。
GitHubが特徴的なのはその料金体系で、GitHub内の自分のプロジェクトのソースを誰でも見えるように設定した場合に限り、無料で機能を利用できる(つまり、ソースを非公開にする場合は有料となる)となっており、オープンソースコミュニティが使いやすい仕組みになっているため、マイナーなものからNode.jsのようなメジャーな物まで今やかなりの数のオープンソースプロジェクトがGitHubを開発スペースとして利用しています。
最近では、GitHub前提で構築されているパッケージ管理システム(自動でGitHubからソースやバイナリをダウンロードし、利用可能な状態にしてくれるツール)も多く、もはやGitHubは”オープンソースの要”といっても過言ではないと思います。
今回、Microsoftに買収される可能性が出てきたということで、個人的に気になるのが”中立性”の問題。
オープンソース業界全体において、”自由な開発”が担保されているかどうか、というのは常にセンシティブな話題です。
例えば、もしもの話ですが、GitHub買収後にMicrosoftが自社の経営戦略にそぐわないGitHub上のプロジェクトを排除しようと思えば恐らくできてしまうでしょうし、そうでなくても、GitHubのサービスをMicrosoftのサービスに特化させたような仕様に変更してしまえば、GitHubを使う他の企業やプロジェクトに対しても不公平が生じてしまう可能性がでてきます。
最も、昔と違って最近のMicrosoftはオープンソースに対してかなり友好的かつ積極的な印象で、Microsoft自身も最近はオープンソースアプリをリリースしたり、自社製品に取り入れたりするようになったので、恐らく上記のようなことが起こらないように慎重な配慮をしていくのではないかと個人的には思っています。
ただ、飽くまでMicrosoftはプロプライエタリな製品がメインな企業なので、今後オープンソース業界全体がどのような反応を見せるのかはとても気になるところです。
個人的には、なんだかんだ言って開発者の多くがWindowsなどのMicrosoftの製品を使ってますし、今までのGitHubにプラスαされる形でより開発しやすくなるような機能が追加されていったらいいな、と思っています。
著者:takahashi
NHKラジオがRadikoでリアルタイム配信の試験を開始
先日、ふとRadikoを立ち上げたところ、NHK系列のAM/FM局が選局リストに追加されていました。
NHKはもともと、独自のサイマル放送サイト”らじるらじる“で配信していて、例えば、スマホで今いる地域のラジオ局を可能な限り網羅しようとする場合は、Radikoアプリとらじるらじるアプリの両方を入れる必要がありました。
そんなNHKとRadikoですが、NHKと民放連との共同ラジオキャンペーンの一環として、2018年4月12日から2019年3月末まで、全国47都道府県でradiko.jpからNHKラジオが聞ける実験配信を開始したとのこと。
radikoでNHKラジオの実験配信、4月から全国で 無料でライブ聴取可能 – くらテク
ということで、当分の間は多くの地域でRadikoアプリ一つでNHKも含めた各局のラジオを高音質で聞くことができます。
折角なので、普段ラジオをあまり聞かないよ～という方もこの機会にラジオの魅力を再発見してみてはいかがでしょうか？
著者:takahashi
Windows版Twitterアプリが久々の更新
先日、TwitterのWindows向けアプリが超久々にアップデートされました。
Windows 10向け「Twitter」アプリが刷新、“Progressive Web App”として生まれ変わる – 窓の社
Twitter for Windowsはここ最近まったくといっていいほどアップデートされておらず、一部新機能も利用できない状況でした。
個人的にはMac版Twitterクライアントと同様に廃止になるのかな…と思っていたのですが、先日突如としてアップデートが降ってきました。
上記の記事にも書かれていますが、このアップデーはおそらくWindows10にPWAの機能が実装されたことによるものだと考えられます。
Windows 10における“Progressive Web App（PWA）”は、Webアプリをネイティブアプリのように使えるよう、UWPアプリとしてパッケージ化したものと言える。一般のUWPアプリと同様、「ストア」アプリからインストールし、［スタート］画面やタスクバーにピン留めして起動可能で、独立したウィンドウをもつが、実質は「Microsoft Edge」上でWeb版“Twitter”を表示しているに過ぎない。
つまり、一見WindowsネイティブなUWPアプリに見えるわけですが、実際はただアプリ内でEdgeブラウザを呼び出して特定のサイトを表示している形になっているようです。
かといってブラウザ版と同じというわけではなく、アプリならではのメリット(UWPアプリの”共有”機能や通知など)も享受できるという仕組みです。所謂AndroidやiOSアプリの”ハイブリッドアプリ”と同じような仕組みです。
恐らく、開発コストの少ないWebベースのアプリであれば、公開し続けられるだろうという判断になったのだと思います。
ただ、Webベースであればアプリを公開できるということなら、既存の仕組みでElectronなどもありますし、macやlinux版もリリースしてくれればよかったのに、と思わなくもありません。
いくらWebを表示しているだけとはいえ、ブラウザを開くことなくワンクリックでアクセスできるかどうかでかなり使い勝手が変わってきます。
Windows以外のデスクトップOS用のクライアントも復活してほしいですね。
著者:ym
google play music から youtube remix
年内に Google Play Music が終了するらしい記事。
「Google Play Music」、年内に終了し、ユーザーは「YouTube Remix」に統合か？ – ITmedia NEWS
自分の持ってる CD をせっせと Google Play Music へアップロードして使い始めたばかりなのに。
勿論、自分のCDなので無料枠ですがｗ
YouTube Red のウェブサイトをみる限りでは同様の音楽機能がありそうですが、まだ日本では利用出来ない様です。同額で有料動画サービスもできる様になるよ、ということか。
無料枠はあるのだろうか。心配です。有料化になり辛い時代になりましたね。
著者:takahashi
自宅サーバーを始めるときに最低限気を付けたい3つのこと
最近、自分の周りで、自宅サーバーを始める方が増えてきました。
自分も自宅サーバーを稼働させているのですが、今回はサーバーについて今まで勉強してきた中で、始めるにあたって最低限気を付けたいことをまとめてみました。
-
OSやファームウェアのアップデートは可能な限りこまめに行う
LinuxやWindows、サーバーを構築するにあたって、必ず何かしらのOSをセットアップするかと思います。
このOS、人間が作っているためどうしても何かしらのバグが出てくる可能性があります。
このバグですが、場合によっては権限のない利用者に対して管理者の許可なくサーバーを操作する手段を与えてしまう”脆弱性”になる可能性があります。
大抵の場合、これらの脆弱性は、開発元が定期的に修正したものを配信しており、それを受信・適用する”アップデート”機能が必ず備わっていると思います。
普段使っている、使うときにしか電源を入れない”クライアントPC”は通常直接インターネット上に公開されていない上に、ネットワーク上にその存在があるかどうかも調べなければ外部からは分からないので、アップデートをさぼっていてもすぐにやられる可能性はまだ低いですが、サーバーの場合はインターネットからいつでもアクセスできる状態である上、その存在もネット上に一般公開されているため、だれでも簡単に接続できます。したがって、脆弱性が見つかったら直ちにパッチをあてないと侵入されてしまう危険性が出てくるのです。
ただ、実際のところ、パッチを適用する際にOSの再起動が必要になることも少なくありません。
実際に運用する際は、アップデートの有無を定期的に確認するようにし、もし再起動の必要のない更新がある場合はすぐに適用、もし再起動が必要なものについてはあらかじめメンテナンス日時を決めておき、利用者に通知したうえで適用するようにするといいと思います。
OS以外にも、使用しているネットワーク機器(ルーターなど)や、仮想環境で使っている場合はホストマシンのOSやハイパーバイザーのアップデートなども併せて確認しておきましょう。
-
メールの不正中継対策を行う
自宅のサーバーでメールサーバー(SMTP)を建てる場合、特に注意しないといけないのはメールの不正中継対策です。
例えば、自分のサーバーでSMTPサービス(postfixやsendmailなど)を立ち上げ、外部からアクセスできるような状態にしている場合、SMTPサーバーから認証なしにメールを送信できるようにしていると非常に危険です。
スパムメール業者などは、使用しているメールサーバーから大量に迷惑メールを送信している関係上、各メールサービスプロバイダからブロックされやすい為、常にブロックされていない新たなメールサーバーを探している可能性があります。
もし不正中継対策をしていないSMTPサーバーを公開してしまうと、こういった業者に、迷惑メールやウイルスメールなどの送信に使われてしまう可能性があります。
もし上記のようになってしまった場合、たとえ自分が送ったわけではないことが証明できたとしても、社会的信用を失ったり、場合によってはその責任を求められる可能性が出てきます。
パソコンが「踏み台にされる」という表現を目にすることがあります。踏み台にされると何が起きるのか、またどんな対策をすればいいのか教えてください。 – マルウェア情報局
対策として、自分のSMTPサーバーを認証なく利用できないように設定しておくと、不正中継を防ぐことができます。
【図解】初心者にも分かるメールの仕組み（SMTP、POP、IMAPの違い) – SEの道標
また、自分のサーバーが不正中継されない設定になっているかテストができるサイトがあります。
-
火事に注意
こちらは技術的な話からは離れるのですが、自宅で24時間PCを動かしていると、サーバーマシンが壊れた際に火事になるリスクがあるようです。
ノートPCをサーバーにして大惨事になった話 – VPS比較メモ
危険なのはノートPC、UPSなどのバッテリーを積んだ機器を使って稼働させている場合。
特にノートPCは持ち運びできるようにするために筐体を小さくすることに重点を置いて設計されており、長時間動作させることはあまり想定されていないようです。
そのため、サーバーのような24時間稼働させるような使い方をすると熱がこもり、バッテリーの爆発や中にたまったほこりなどに引火して火事になってしまうことがあるようです。
一方、デスクトップPCの方も火事になることはあまりないようですが、電源周りがショートして中で火花が飛ぶ、といったことが起こる可能性はあるようです。
自作PCからの出火が原因で火事になる確立はどのくらいでしょうか？- Yahoo!知恵袋
こちらもやはり、定期的なメンテナンスを設けて、ほこりの除去などの定期的な手入れをした方がよさそうです。
また、監視ツールなどを使ってハードウェアの状態を常に監視しておくことも有効かもしれません。
-
最後に
自宅サーバーの稼働には確かにリスクがあります。
それ故に「VPSなどを使えば事足りるし、安くて安全だし、自宅にサーバーを置くべきではない」という論調も目立ちます。
しかし、実際のところは、ガッツリサーバーを利用したい場合はVPSはかなり高くつきます(例えば、1TBのストレージを使おうと思ったら、自鯖ならHDDを追加すれば済みますが、VPSやクラウドの場合は月額でだいたい1万弱かかります)し、ハード構成やネットワークも含めて、一から自分で設計・構築ができるのはかなり魅力だと思います。
また、データはすべて自分が管理しているマシンの中に納まっているので、業者の不手際による情報流出や情報の不正利用のリスクを防ぐことができます。
ちなみに、有名なITニュースサイト Gigazine は、自分たちの発信する情報に対して圧力がかかっても公開が停止させられることがないように、という理由で、敢えてオンプレミスで運用している、という例もあります。
海外にディザスタリカバリを複数箇所設置 – Gigazine
自宅サーバーとクラウド(VPS)、どちらが優れているのかはそのままオンプレミスかクラウドか、の議論に発展していくわけですが、個人的にはこの議論はナンセンスだと思っています。
クラウドもオンプレミスも一長一短があり、どの形態が適しているのかは自分がどういったサービスを建てたいのかで決まってくるからです。そしてその選択肢として、クラウド(VPS)も自宅サーバー(オンプレミス)いずれもなり得えるということです。
また、どちらを選んだとしても、ネット上に自分の環境を公開することはリスクを伴います。そのリスクに対してどう対応していくか、考えていくのも勉強の一つだと思います。
普段何気なく利用しているWebサイトやWebサービスですが、その裏側がどうなっているのかを知ることはとても面白いです。
自分が構築したインフラやコンテンツが、インターネットを通じて全世界の人に見てもらえることの楽しさを、ぜひ多くの方が体験出来たら素敵だな、と思っています。
著者:takahashi
スマートフォンで本格的な緊急地震速報が受信できるアプリ “Signal Now Mobile”
先日からちょくちょく南海トラフ自身の話題がTwitterなどで上がっていました。
南海トラフ地震のニュースしてたからシュミレーション見てみたら怖すぎた。 pic.twitter.com/nuUaT07XQH
— めあ@フォロバするよ(´˘`＊) (@Night_1358) 2018年4月12日
もし南海トラフ地震が起きた際の静岡県内の被害は甚大で、想定死者数は10万人を超えると予測されています。
地震が起きた際、生存率を少しでも上げる方法として、情報をいかに早くキャッチして、適切な行動をとれるか、というのも助かる要因の一つになるのではないかと思います。
自分の場合、詳細な緊急地震速報を受け取るために、自宅のPCにSignal Now Xというアプリをインストールしてあります。
このSignal Now X 緊急地震速報を受信すると、警報音とともに、あと何秒で津波が到達するかを教えてくれる、高度なアプリとなっています。
ただしこのアプリ、Windowsにしか対応しておらず、PC向けなので持ち出せないというデメリットがありました。
そんな中、同じシリーズでスマートフォン版があったことを先日知りました。
SignalNow MObile = Google Playストア
その名前もSignalNowMobileです。
月額100円の有料とはなりますが。SignalNoｗXで取得できるような、あと何秒後で地震が到達するか、まで教えてくれます。
キャリア標準の緊急地震速報も強力ですが、秒数が表示されるアプリは今のところこちらだけな気がします。
巨大な地震も、普段から準備しておくことで少しでもリスクを減らすことができるはず。
備えあれば憂いなし、ですし、今のうちから準備をしておきたいですね。
著者:takahashi
AWSの料金をシンプルに計算してくれるサイト
AWSの料金計算って、わかりづらくてめんどくさい…
なんて思っている方結構いると思います。
そんな方にピッタリなサイトを発見。
その名も
現在8個のサービスの見積もりを出すことができるようです。
今回は試しに、EC2の方を試してみます。
個人の小規模なサイトを想定してこんなもんかなーと入力してみました。
おおお！料金が出た！
値を入力してくと自動で合計額が増えていく仕組みです。
AWSのシステムを把握していない初心者にとっては、これぐらいシンプルだとわかりやすくてありがたいです。
ただ、シンプルということもあり、それぞれのサービスで計算できないオプションがあるようで、入力画面の下側に注意事項として書かれています。
オプションサービスを使う方は公式の料金計算ツールを利用しましょう。
なお、こちらのサービスですが、作者の方がQiitaに作り方を掲載しています。
AWSの料金を「ざっくり」計算できるサイトを作るぞ – Qiita
ちなみに、こちらのサイト、イースターエッグも仕込まれているようです。
興味のある方は是非探してみてはいかがでしょうか。
著者:takahashi
ApacheのRewriteでメソッドの種類を条件にした時の書き方
久々にApacheのmod_rewriteをこねこねしたので、その備忘録。
Apacheのmod_rewriteはかなり柔軟な指定をすることができ、それ故に”黒魔術”と呼ばれることもあります。
そんなmod_rewriteですが、プログラムを介することなくGET/POSTなどのメソッドに応じてリダイレクトさせることが可能です。
書き方としては
RewriteCond %{REQUEST_METHOD} ^(メソッド名)$
こんな感じです。
例えば、POSTの時だけリダイレクトしたいのであれば
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(POST)$
RewriteRule ^(.*)$ /post/only/path%{REQUEST_URI} [R=301,L]
のように書けます。
Rewriteは非常にたくさんのオプションを指定でき、柔軟に振り先を分けることができます。
Apacheのmod_rewriteモジュールの使い方を徹底的に解説 – OXY NOTES
ただし、誤った設定をしてしまうと、リダイレクトループに陥ってしまい、ページが表示できなくなってしまうこともよくあります。
すでに動いているサイトなどでは十分に注意して使用してくださいね。
著者:takahashi
TwitterがUserStreamsAPIの廃止を延期
以前から波紋を呼んでいたTwitter Streams APIの廃止問題ですが、どうやら廃止が延期されたようです。
Twitter、“流れるタイムライン”の「User Streams API」廃止を延期 – ITMedia
User Streams APIとは、一度TwitterサーバーのこのAPIに接続してしまえば、リアルタイムにツイートの取得が可能となり、さらに現在サードパーティアプリに敷かれている15回/15分という厳しい取得制限の影響を最小限に抑えられる、唯一の回避策でもありました。
ところがTwitterはこのUser Streams APIも廃止を行い、TLの取得ができず、ほぼ有料であるAccount Activity APIの適用を強制することで、実質的にサードパーティークライアントの締め出しを行おうとしていました。
上記記事ではなぜTwitterがUserStreamsAPIの廃止が延期されたのかは不明と書かれていますが、こちらの記事ではTwitter社に対して抗議が多数寄せられたことが原因としています。
Twitter、サードパーティアプリを破壊する「User Streams API」の廃止を延期 – 携帯総合研究所
情報が錯綜気味なので、実際のところはわかりませんが、”謝罪専用係“や大量アカウント凍結などの事件もありましたし、UserStreamsAPIの廃止によって多数のデベロッパーやユーザーにとってさらに使いづらくなります。ユーザーやデベロッパーから猛烈な抗議が出るのも無理はないと思います。
経営難でいろいろな施策が必要なのは理解できるのですが、利用者数も少ないサービスではないですし、原因はユーザーではなくTwitter側にあるはずなので、ユーザーにばかりしわ寄せするような施策が多いのはどうかと思ってしまいますよね。
制限ではなく、Twitter、ユーザー双方にメリットのあるシステムを考えていって欲しいところです。
著者:takahashi
Mastodon rake タスクが実行できないときの対処法
以前、Mastodonのインスタンスをさくらのクラウドで構築した際の話です。
この時の構築はさくらのクラウドの自動セットアップスクリプトを用いての作業でした。
さくらのクラウドでは、仮想マシン作成時にセットアップスクリプトを設定しておくと、各セットアップ作業を全自動で行ってくれる非常に便利な機能があります。
この機能を使って作成すると、作業を本来必要な作業を大幅に省いて構築ができるため、数時間でサービスの立ち上げまで行うことができます。
このインストール作業自体はさほど問題はなかったのですが、問題が起きたのはセットアップ後の作業。
Mastodonのデイリー処理 mastodon:daily タスクをcronに登録する前に動作テストを行ったのですが、
こんな形でエラーになってしまいます。
Mastodonの情報は大体検索すると出てくるのですが、このエラーは探せど探せど解決方法が見つからない…
結局、本家のIssuesを確認したらあっけなく対策方法が見つかりました。
各rakeコマンドを実行する前に
export RAILS_ENV=production
コマンドを実行するだけです。
実際に試してみたところ、
これだけであっけなく実行できてしまいました…
環境変数を指定しているだけなので、毎回入れるのは忘れそう、めんどくさい、という方は、
rakeコマンドを実行するユーザーの
~/.bashrc
に同じexportコマンドを書き加えてしまえば、指定する必要がなくなります。
調べてみると、初めて触った時にそこそこハマるポイントのようですね(汗
—
この記事は以前自分自身で公開した記事を修正したものです。