GCEでライブパッチは使えなさそう。

手元の端末でcanonical-livepatchが動いてるのを見て、そういえば3台までいけるんだからサーバでも使おうか、と思った。

$ uname -a
Linux yumenosora 4.15.0-1024-gcp #25~16.04.2-Ubuntu SMP Tue Oct 30 14:14:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ sudo snap install canonical-livepatch
canonical-livepatch 8.0.6 from 'canonical' installed
$ sudo canonical-livepatch enable [トークン]
2018/11/19 14:20:31 cannot use livepatch: your kernel "4.15.0-1024-gcp" is not eligible for livepatch updates

にゃうーん。Compute Engine上では専用のカーネルが使われるけど、ソレにライブパッチは使えない、みたい。残念。

手軽にMaterial Designを使うには。

Material Design、いいですよね。
見るだけじゃなくて実際に自分のアプリケーションにも適用したかったので、いろいろ調べてみました。

  1. 自分でCSSやJSを書く。デザイナーならこれか一番早いかも。よく整備されたドキュメントがあるので、それを参考に。
  2. Polymer+Paper Elementsを使う。一番の正攻法?Web Componentsを使った新しい作り方をすることになるのでこれから発展が見込める反面、学習量は多くなる。学んて損はないだろうけど最初は時間がかかるかも。あと、まだプロダクションレベルではないですよね。
  3. Angular Material Designを使う。Angular JSを使って今時な感じで作ってるならすんなり適用できるのかな。別のフレームワーク使ってるとか、レガシーな作りしてるとかだとしんどそう。
  4. Leaf frameworkを使う。シンプルな作りのフレームワークで、マークアップの決まり事も少なく導入しやすい。エフェクトが実装途上だったり再現度は少し劣る?

最初の以外全部試しましたか、ウチでは最後のLeafを使うことにしようかと思ってます。新しく会得するべき内容が少なく済むし、できるだけお手軽に導入したいという場合にはぴったりなんじゃないでしょうか。

限定公開はじめました。

Welcome to nginx!

s
というわけで、限定公開ですが新サービスをリリースしました。(5/7追記: パスワードなしで公開にしました)
このサービス、どういうものなのかいまいち上手い紹介が思いつかないんですが、簡単に言うと、

  • 立ち絵付きのTwitter botのようなものが作れます。(あくまでも「のようなもの」です。Twitterとの連携機能などはありません。)
  • ユーザとしては、実行画面(舞台)を開きっぱなしにしておいて時々見る、もしくは適宜開いて読む。それだけです。
  • デスクトップマスコットをごく単純にしてブラウザに載せたような感じとも言えます。
  • キャラクター(出演者)のデータの作成は例のごとくブラウザ上で作れます。
    • 立ち絵(外観)と話の内容(脚本)の作成は分業もできるし、一人で両方作ることもできます


実行画面はこんな感じ。

表示されているのはデフォルトキャラ。まだたいしてネタの量がないので同じ話が繰り返されるのはご愛嬌。


しばらく限定公開でテストして、不具合など落ち着けば限定を外してリリースする予定です。
どうぞお試しください。

OpalでJavaScriptの要らない開発

は、無理ですけど。
Best Casino Sites in UK - Play at Best Online Casinos in 2018!
このコードトランスレータによって、それに近いことは可能になります。
導入や実際の使い方はドキュメントや解説記事に任せるとして、1週間ほど使ってみて分かったことをいくつか。

ちょっとした非互換性

$ ruby -v
ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin10.8.0]
$ irb
irb(main):001:0> def foo
irb(main):002:1>   5.times do |i|
irb(main):003:2*     return 'foo' if i > 3
irb(main):004:2>   end
irb(main):005:1>   
irb(main):006:1*   return 'bar'
irb(main):007:1> end
=> nil
irb(main):008:0> puts foo
foo
=> nil
$ cat app/assets/javascripts/foo.js.rb 
def foo
  5.times do |i|
    return 'foo' if i > 3
  end
  
  return 'bar'
end
puts foo

JSコンソールの出力

bar

ブロック中でreturnした場合の結果が違う

ファイル分割

foo.js.rb

def foo
  puts 'foo'
end

bar.js.rb

puts foo

JSコンソール

foo

定義したモジュール、クラス、メソッド等は別のファイルに書いたコードからでも使える。
rubyコード中のrequireは意味がないようだ。

JSからRubyで書いた処理を使う

fooというメソッドをトップレベルで定義した場合、

Opal.top.foo()

でアクセス可能。

module Foo
  def self.bar
  end
end

とした場合は

Opal.Foo.bar()

で触れる。

リリースしました。

本日、読書びよりの新版"Hibarigaoka-hanayashiki"をリリースしました。
主な変更点はデザイン・画面の全面刷新です。
今回の改修ではメディアクエリを活用して、画面サイズに応じて最適な表示を行うようにしてあり、スマートフォンタブレットでも利用できるようになってます。

PC


画面幅に応じてカラム数が変動します。

スマートフォン

http://p.twimg.com/AX5suEoCQAA06N8.png
小型画面のためにいくつかの要素を表示しません。

限定公開機能を考える。

カケラの樹には限定公開機能が実装されており、非公開文書を特定のユーザのみに公開することが可能になってます。
概要としては、

  • 限定公開したい相手のOpenID URLを設定
  • 相手は自らのOpenIDにてカケラの樹にログインし、文書を開く

この機能はサービスの初期から実装されているものですが、以下のような設計上の問題を抱えています。

  • 相手のOpenID URLが必要
    • はてなライブドアのように外部サービスのユーザIDから簡単に作成できるならまだ良いが、GoogleのもののようにランダムなURLを使っている場合、URLを知ること自体が難しい
  • 閲覧時にログインが必要
    • 外部認証ではあるが、初回ログイン時の操作が必要となる。
  • 許可リストの視認性が悪い
    • ランダムなURLの場合に特に問題


置き換え候補としては、以下の二通りが考えられます。

登録ユーザから許可するユーザを選ぶ

メリットとしては、

  • 対象ユーザを検索などで探し出し、グラフィカルに追加可能で操作性がよい

デメリットとして、

  • ユーザ検索機能などを新規に構築する必要がある
  • 未登録のユーザに公開したい場合、あらかじめユーザ登録をしてもらった上で対象にする必要がある

ランダムなURLを使用する

メリット

  • 構造が非常に簡単
  • 使用方法も簡単
  • 閲覧の際にユーザ登録が不要

デメリット

  • セキュリティ的には弱い


後者への置き換えを軸に検討中です。