余計なgemをVSCodeとbashでまとめて削除する
gem listを実行すると、以下のようにずらっと出てくる。
$ gem list *** LOCAL GEMS *** actioncable (5.2.0, 5.1.4, 5.1.2, 5.0.6) actionmailer (5.2.0, 5.1.4, 5.1.2, 5.0.6, 4.2.5) actionpack (5.2.0, 5.1.4, 5.1.2, 5.0.6, 4.2.5) actionview (5.2.0, 5.1.4, 5.1.2, 5.0.6, 4.2.5) activejob (5.2.0, 5.1.4, 5.1.2, 5.0.6, 4.2.5) activemodel (5.2.0, 5.1.4, 5.1.2, 5.0.6, 4.2.5) ...
結果をコピペしていらないやつだけにしてgemList.txtで保存。 このとき表示されるバージョン一覧[ex). (5.2.0, 5.1.4, 5.1.2, 5.0.6)]が、gem uninstall GEMNAMEするときに不要なのでVSCodeを使って消す。 正規表現で"/ (.+)/" -> ""に置き換えれば済む。VSCodeがなかったらrubyとかでさくっと処理。
File.foreach('gemList.txt') do |line| puts line..gsub!(/ (.+)/, "") end
あとはbashでgem uninstall -aIx GEMNAMEを実行するファイルを書く。ここで-aIxオプションをつけておく。
-a, --[no-]all Uninstall all matching versions
-I, --[no-]ignore-dependencies Ignore dependency requirements while
uninstalling
-D, --[no-]-check-development Check development dependencies while uninstalling
(default: false)
-x, --[no-]executables Uninstall applicable executables without
confirmation
cat gemList.txt | while read line do sudo gem uninstall -aIx $line done
疑問
試してないけど、もしかしたら途中のreplace処理いらないかもしれない。
kindle paper whiteを購入して1年半が経ったのでレビュー
メリット
1. これ一つで図書館を持ち歩ける。
雑誌やライトな小説など一冊単位の文量が少ないものをよく読む場合、一冊では事足りず沢山持ち歩かなければならないので、そういったときに便利。
2. 片手で読める。満員電車でも読める。
通常、紙媒体の本を読もうとすると、両手でホールドして読まなければならず疲れる。
kindleであれば端末が軽いので片手で済む。
ページめくりも片手の指で済むので全てが片手で完結する。
満員電車で本を読むためのスペースを確保するのは憚られるが、片手だけであればスマホをいじるときと同様のスペースで本を読めるのだ。
電車内の読書時間を増やせるのは嬉しい。
3. kindle端末を忘れても、他端末（携帯, PC）があれば読める。
稀にkindleを忘れてしまうことがある。
そんなときでも大丈夫、携帯にkindleAppを入れておけばいつでも続きから読むことができる。
紙媒体なら忘れたら終了。
4. kindle版だと値段が安いことがままある。
これは「紙・印刷・運搬などのコストが浮いているそうだろうな」と普通に思うが侮るなかれ。
確かに通常の本は-100円ほどの些末な割引額ではあるが、一方でkindle版のみの特大割引セールも存在するのだ。
技術者にとっては目から鱗で、-70%の場合もちょびちょびあるので嬉しい。
5. kindle unlimitedで特定の雑誌、小説を月幾らで読める。
月700円程度でamazon側がセレクトした小説、漫画、雑誌を際限なく無料で読める。
雑誌の更新頻度半端ないってぇぇえ。
6. 本をなくすことがない。
毎月多くの量を読んでいるといつのまにか積読本が消失していることがあるので、そういったことがないクラウド保存最高。
7. 引っ越しの時に楽
(1)の要素だが、大きな要素なので改めて記載。
読書家で引っ越しが多い・転勤が多い人にとって、本を持ち運ぶのは億劫以外の何者でもない。
引っ越しのとき、わざわざダンボールに詰めて運ぶ必要がないので本当に楽だ。
8. スーパー軽い
205gなので持つ腕に負担がない。
ずっと片手で持っていられる。
デメリット
1. 本を三次元的に認識することができない。
本は三次元的に読むものだ。
例えば、「本の後半にぐっとくる場面があったんだよなぁ、またあの場面を読みたいなぁ」となったときに、紙媒体の本であれば、明確ではなくともだいたいのページを指で覚えているのですぐその場所まで飛ぶことができる。
しかし、kindleではしおり機能を使えるものの、それは読んでた時に重要と思った点だけに使える機能。
ふと思いついたときは、そりゃもう大変。。
小説のようなストーリー性のあるものであればまだマシだが、専門書などリファレンス用に扱う本だと尚更。
2. 図表とテキストを照らし合わすのが大変
「右図の〜」とか「グラフ1が〜」とかの右図、グラフが同ページに収められていないときが多い。
紙媒体であれば読みやすいようにデザインされているが、kindleだと画面の都合上で途中でカットされて表示されるので照らし合わせにくい。
3. 紙ざわりを味わえない。
もちろんペラペラ感は得られない。
4. コレクション性がない。
読んだ本を本棚に保存しておきたいという方には絶対に向いていない。昔読んだ本はページネーションでどんどん後ろになっていくので、目につくことはなくなり、少し寂しい気持ちもする。
5. 複数書籍を開きたいときに使えない。
kindleには複数書籍を並べて開く動作がない。そのために複数書籍を開くためにはいちいち切り替える必要がある。
これは不便だ。なので、リファレンスや教材目的の書物であれば紙媒体の本をおすすめする。
6. 貸し借りができない
おすすめの本！というのは友人に紹介したくなるもの。
なんだったら布教活動の一環であげちゃってもいい！
そうはいかない。本を横流しにしがちな人には向かない。
論文評価
情報処理学会の『表示媒体が文章理解と記憶に及ぼす影響ー電子書籍端末と紙媒体の比較ー』という2012年の研究論文によると比較実験の結果より以下のように結論づけている。
(1).読み速度の結果,説明的文章では,iPadの方が紙より早く読むことができる.
(2).記憶テストの結果,説明的文章では,紙の方がiPadよりも記憶成績がよい.
(3).理解テストの結果,文学的文章と説明的文章のいずれも,紙の方がiPadよりも理解成績がよい.
紙媒体の方が総合的に優れていると結論づけられているが、一方で考察では実験では測れないこれまでの経験値について着目している。
しかしながら,これをもってただちに電子書籍端末が学習に不向きとすることは早計だろう.電子書籍端末はあくまで新しいメディアであり,紙との読み慣れの差は比較にならないほど大きいことを考慮する必要がある.
読み慣れの差がこの研究に影響を及ぼしていることを考慮に入れる必要があると述べている。
つまり、読み慣れを電子媒体に適正化することで電子媒体による理解度が紙媒体とほぼ同等になる可能性を示している。
ただし、これまでに幼少期から慣れ親しんだ紙媒体での読み慣れを一朝一夕に超えられるはずがないのは当然のこと。
小説などのストーリーものは電子媒体で読み、教材や専門書などの理解を強いる書物に関しては紙媒体で読むという使い分けスタイルがいいのではないかと思う。
まとめ
小説・雑誌大好き人間は買った方がいい
参考文献
Swift 4+CakePhpでのログインを自分なりに実装してみた。
通信にAlamofireを使用する。
Swift側処理
// CakePhpの$users = $this->User->findメソッドの返り値が$users['User']['title']になり、 // 中間の['User']をCodableに対応させるためにこのような実装にした struct Users : Codable { let user: UserBox } struct UserBox : Codable { let User: UserContent } struct UserContent : Codable { let name: String let age: Int } class ViewController: UIViewController { @IBOutlet weak var emailAddressField: UITextField! @IBOutlet weak var passwdField: UITextField! // ボタンが押された時にユーザー情報をAlamofireによって送信する。 @IBAction func onButtonTap(_ sender: UIButton){ if emailAddressField.text != "" && passwdField != "" { let params: Parameters = [ "User": [ "emailAddress": emailAddressField.text!, "password": passwdField.text! ] ] // Alamofire(リクエスト用ライブラリ) [https://github.com/Alamofire/Alamofire/blob/master/Documentation/Usage.md] Alamofire.request("http://hoge.com/Users/login.json", method: .post, parameters: params, encoding: JSONEncoding.default).responseJSON{ response in if let data = response.data { // レスポンスデータをJSON形式で受け取り、Codableを利用して構造体に入れる。 // Codable [https://dev.classmethod.jp/smartphone/json-decoding-without-swiftyjson/] let feed = try? JSONDecoder().decode(JSONFeed.self, from: data) // 取得情報処理... } } } } }
CakePhp側処理
<?php class UsersController extends AppController{ public $uses = array('User'); public $components = array( 'RequestHandler', 'Auth' => array( 'allowedActions' => array('login'), 'loginAction' => array('controller' => 'Users', 'action' => 'login'), 'authenticate' => array('Form' => array('fields' => array('username' => 'emailAddress'))), ), ); public function login(){ if ($this->Auth->login()){ $user = [ "emailAddress" => $this->request->data["User"]["emailAddress"], "login" => true ]; // JSONで返す // {"user" : {"User" : {"name" : "hoppy", "age" : 21}}} $this->set([ 'user' => $user, '_serialize' => ['user'] ]); } else {...} }
まとめ
ログインするためにログイン用のviewControllerを適当に作成する。
textFieldを二つおいて、それぞれをemailAddressField, passwdFieldとし、ボタンを一つ置いて、セグエで繋げる。
レスポンスデータをJSON形式で受け取り、Codableを利用して構造体に入れる。
感想
CakePhpとCodableの組み合わせがクールじゃないのでここをスマートに書く方法を知りたい。
ぼやき
徒然なるままに再び記事を書いていきます。ブログを継続させている人ってすごいなぁと思った、Youtuberとかブロガーとか毎日何かを生み出しているわけで、それを習慣化させるのはとんでもないバイタリティ。しかもその日々の努力が他人から評価されて、もしかしてもしかすると食っていけるってんだから凄まじい世界。
日記として書いておくと、丁度IT企業のインターン？（実質的には契約社員的な感じで月幾らで働いている。聞こえの良い風に変換するとフリーランサーを名乗れるかも）を始めたのが7月の頭なので、早九ヶ月が過ぎた。まじか！九ヶ月も過ぎたのか！とこの記事を書きながら驚いている。最後に日記を書いたのが8月の終わりでそのときから数えても半年経っている。この期間で成長したことはrails,aws,jqueryと少しのアルゴリズムと英語力、真面目力かと。真面目力に関して言えば、一年ぶりくらいにバイト先の先輩に会ったら「なにまともになろうとしてんだよwwあの麻雀で食っていくって言ってたお前は何処にいったんだ」と言われるくらいには著しい成長を遂げた。まさか自分でもずぅ〜とプログラミングしている風になるとは予想だにしなかった。でも1日12時間週5で半年間麻雀ずぅ〜とやってたのと一点突破の根本は変わってないのに評価は変わってるのが面白い。
つぶやきのごった煮
w-indsのライブ動画を久々に見て、「あぁー、Can’t get backは2009年なんだなぁ」とぼんやりと思った。サビの部分の「I cant get back, love you again だけど手遅れ..」のとこでは、勝手に体が動きだしたぐらいには踊れるもんだった。よく漫画とかで師匠的な存在が「身体に染み込ませろ！」ってな言葉を言ってるけど、自転車にしろ水泳にしろダンスにしろ一回ガッツリやったものは、本当に人並み以上に出来て、腐っても鯛ってことわざはかなりしっくりくる。またそのことわざについてだけど、腐っても鯛だったら、腐る前はなんだったんだろうなぁと考えてみたり。それで小学生時代に出した結論がギャラドスだったわけなんだけど、その理屈だったら元が超一流ならばメガギャラドスに代替できると思うと面白い。例えば、つい先日に世界陸上を最後に引退試合をしたボルトに対してだったら、「足速いなぁ、腐ってもギャラドスだわ」となる。いやあんま面白くないわ。
とかく、ライブ映像を見ての一番の感想はやっぱり涼平くんは変わらないなぁということだった。荒木飛呂彦ばりの若々しさを保っていて、このまま永遠に王子さまなんじゃないかってくらい。絶対にWRYYYYYYYしてるよ。
それと最近あった出来事では...少し前に一週間くらい前になるけど広報局の夏合宿があった。ずらっとまとめると、浜中湖に2泊3日で行って、そば体験して、ペンション着いて、酒飲んで、起きて、トランプやって、bbqして、酒飲んで、バーミアン行って、マージャンして、帰ってきた。基本的に老害ズで行動していたので、まるで4人の慰安旅行であったのだが、非常に楽しかったな。なにより一番の収穫は、古賀政男という作曲家を知れたことか。浜中湖周辺に置いてあるとあるでっけえ石、そこに近づいたのが条件で急に音楽が流れ出し、カラオケスタイルで歌わせられる。碑文に歌詞が乗ってあるものの、もちろんのこと全くメロディーとの合わせ方がわからないので歌えない。と思ったら、突如として隣の山中が『呼び込みくん』のBGM（https://www.youtube.com/watch?v=b7pzTtrnUyc）を口ずさみ始めて、せっかくのメロディーの一切をかき消してたのはすげぇ笑ったな。
それと本日を持って、Yosemiteから卒業してSierraにしました。理由はxcodeのアップデートのタメ。あと毎日一冊読書できたらなんて思ってたけど、一週間に2冊程度がちょうど良い。主に読書する時間が電車乗ってるときで、家に帰ってから読もう！っていう気は起こらない程度の読書好きであると自覚。技術書も読書のカウントならば、週４冊程度かも。
最後に集合写真、チームC4は何処へ。
ドラクエとは素晴らしいものだ
バイト先の高田馬場までの運賃がなかったためにどうしようもなく自転車で60kmの行程を全力で漕ぎに漕いだ。自分の愛用していた８マンのクロスバイクは、昨年度、溝の口周辺の駐輪場に駐車していた際に盗られてしまったので、母親の愛機の電動付き自転車を借用した。出発する前までは、「弱虫ペダルの小野田くんもアキバまでの往復100kmをママチャリで行けてんだし、余裕っしょ！」といった勢いに乗っていたわけだが、いざ20km地点の代々木公園辺りまで来てみると、「あっるぇ〜、これしんどくね？てか交通量多すぎて怖っ」っという思いが湧き出てきた。行きの段階でひいこらひいこら言いながら漕いでやっとこさバイト先に着いた。そこで２時間ほどの会議が終わるやいなや復路である。
復路は壮絶の一言に尽きる。開始10kmにして電動チャリの充電が切れたためだ。これによって、一般のママチャリより厳しいハンディーを課せられた私は一層の地獄に突き落とされた訳である。命尽きた充電器と2.5kgの2012年製Macbook proを余分に背負いながらの旅は大変に苦しいものだった。私史上、ここまでの地獄は、中学時代に50m息なしクロールをした以来である。ようやく見知れた場所に帰ってきたときの感動といったら凄まじいもので、ラストスパートを追い込む私の耳には、「大長ガンバレ！」の声が鳴り響いておりベルリンオリンピックもかくやというほどであった。
今回の行程を振り返ってみて、なぜこんなにも苦境に立たされたのかと疑問に思ったところ、それは携帯を持っていなかったからであるとの結論に達した。現代において、スマホとはまるで魔法だ。普段よりそれに頼りっきりの私にはGoogleMapなくしての旅は完全なるアドベンチャーだった。豪邸が水平線まで立ち並ぶ世田谷区などは、私にとって未知の世界であり、アドベンチャーに不可欠なもやもやとした黒い感情が駆り立てられたものだ。かといって、良い思い出もあった。
それは、下北沢という駅はなかなかに面白そうな駅だと気づけた点だ。東西南北に大きく広がっているように思えた下北沢駅の城下町は、22時頃であるのにも関わらず、ほとんどの店が営業しており、かつ客席は多く埋まっていた。街並みは活気に溢れていて、子連れの家族から路上で汚く眠る学生、3, 4人で連れ歩くサラリーマンまで老若男女揃っていて、その色鮮やかさはドラクエのパルミドを彷彿とさせた。話は変わるが、ドラクエの世界は酔い潰れるおっさん、ギャンブルに明け暮れるおっさん、人の物を漁る勇者などなどのクズが許される傾向にあるので、そんな懐の深いドラクエワールドに是非とも流行りの異世界転生してみたい。なるべくなら、ニマ大師にケツを叩かれて、ロウの記録を更新した変態師として名を馳せたい。
「KISS」 ブログ開設一言目がエッセイ
「Keep It Simple Stupid.」 これはプログラマにとって鉄則ともいえることわざで、日本語に訳すると「単純にやれ馬鹿野郎」ということであり、コーディングにおいて一番に優先されるのは単純さであることを四文字で伝えている。プログラマにとっての一番の敵は、複雑で絡みあった汚いコードであり、冗長にかかれたものを嫌う傾向は、ただでさえ短いことわざを更に四文字に縮めていることからも理解できる。特に煩雑で重複した内容のものはスパゲッティコードと呼ばれ忌み嫌われる。コーディングは単純明快が一番であり、１つの関数の行数も多くて１００行前後であることが望ましく、それ以上の場合は関数を分けた方が可読性が高まる場合が多いと言われている。
また、現代コーディングの流れとしてオブジェクト指向が要求されることが多い。コードをオブジェクトとして囲うことでブラックボックス化にして単純にすることで、自分が理解する必要がある機能かどうかを区分けして可読性を上げ、発展とともに増々複雑になっていく技術の積み重ねに対処している。ずばぬけて簡潔に纏められたコード群は、ライブラリーとして多くの開発者に恩恵をもたらし、それによってまた新たなコードが生み出される。
単純なものの代表の例で言えば、数学や物理学で用いられる公式が挙げられる。公式は、多くの研究者の追求によって洗練を重ねた単純さの純粋結晶であるといえる。最も端的にまとめられた公式の１つとして、『ファインマン物理学』で紹介されたオイラーの公式が有名である。この公式は指数関数と三角関数による究極の結論だ。その証明には微分・積分への理解が必要であるが、公式自体には含まれていないため大変わかりやすい。理学と工学のどちらの分野においても頻繁に利用されているので、この公式なくしては現代の科学技術が成り立たっていなかったのは確実である。
また私達が日常で触れる例で言えば、２ｃｈまとめサイトが最たる例であろう。有象無象のスレッドから注目すべきスレッドのみをまとめ、更にはその中のレスをも重ねて厳選したのがまとめサイトである。２ｃｈというサイトを単純に読みやすくしただけであるが、有名まとめサイトのPV数は凄まじく、それがビジネスとして成立しているのだから単純さの恐ろしさがわかる。
これらの例から考えられるに単純さとは、情報伝達においてかなり重要である。もちろん、相手方に物事の100％を伝えるには、オイラーの公式の証明の如く、非常に事細かに伝えなければならない。確かに、時間がある場合であれば、この方法がベストであるものの、社会において多くの場合は制限時間を設けられた状況で説明する場合が圧倒的だ。例えば、新企画の説明のための会議などがそうである。会議において自分一人が長い間喋ることはできない。やはりそこで求められるのが、単純さである。
相手に伝えたい情報量の差異が単純か否かという違いを生じさせる。言い換えれば単純さとは「詳細な背景を隠して相手に物事をわかりやすく伝える技術」であり、つまるところ情報の取捨選択である。私自身、理工系で凝り性が災いしてついつい長話をしてしまうときがある。そのときに「話が長い」「わかりにくい」と指摘されたので、話のキーワードだけの会話にすることを心がけたところ、同じ話の印象ががらりと変わった。情報化が日進月歩に進む現代において、いわずもがな情報は力を持っている。その際に、発信した情報が生きるか死ぬかは単純にする技術に依るところが大きいと考えられる。すなわち、単純さが、たかが単純さとはあなどれない強力な武器になり得るのかもしれない。
