Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

S3で302リダイレクトをする（301リダイレクトでなく）

AWS

AWSのS3でリダイレクトの設定ができます。

例えば https://hirokiky.org/ 以下へのアクセスをすべて https://blog.hirokiky.org/ にリダイレクトするなどです。

簡単な設定（301リダイレクト）

S3の親切な設定を使うと簡単に設定できるのですが、 301リダイレクトになります 。

バケットの Properties => Static website hosting => Redirect requests で簡単に設定できます（以下の画像のように）。

f:id:hirokiky:20180123173128p:plain

302リダイレクトする設定

代わりに Use this bucket to host a website という静的サイト配信用の設定から 302 リダイレクトを設定できます。

この RedirectionRules を設定することで 302 リダイレクトができます。 以下の設定は https://blog.hirokiky.org/ に 302 リダイレクトする設定になります。

f:id:hirokiky:20180123173159p:plain

XMLの内容は以下です。

<RoutingRules>
    <RoutingRule>
        <Redirect> 
            <HostName>blog.hirokiky.org</HostName>
            <ReplaceKeyWith></ReplaceKeyWith>
            <Protocol>https</Protocol>
            <HttpRedirectCode>302</HttpRedirectCode>
        </Redirect>
    </RoutingRule>
</RoutingRules>

index document の設定はテキトウに index.html などで良いです。

他にもオプションを指定できるようなので、以下から参照してください。

docs.aws.amazon.com

簡単な設定はこのオプションの設定をラップしているんですかね。 ともあれ色々設定もできて便利です。

製品を使ったときに余地を感じられるかどうか

考え

まえがき

これは僕の雑記なので、あまりマジメに言及することはオススメしません。 どんな人が読んでも、読む人にとって不快感のないよう配慮しておりますが、内容の正確性や面白さ、情報としての価値は保証しておりません。

本文

製品を使ったときに、自分の人生がこう変わるかもしれないと感じれるものを作りたいと思っています。 人は根源的に、自分の生活や人生を変えたいと思っているものだと僕は考えています。 それは劇的に自分の何かを変えたいと万人が思っているというわけではなくて、日々自分の生活を豊かにしたり、 自分にとって「違うもの」に触れたり、避けたりして自分の人生を変えたり、守ったりしたいと思ってるという意味です。

僕は、人が製品に触れたときに、その可能性を感じれるものを作りたいと思っています。 それには「余地」が必要だと思っています。使い手が自分自身で解釈して、自分自身の人生に適応していく余地が必要だと考えています。

そのために、僕は「シンプル」であるべきだと考えています。「シンプル」という定義も曖昧なので難しいですが、多くの製品は僕の感じるシンプルとは違うように思えます。 シンプルである、ミニマルであると言いつつ、使う人にとっての可能性の余地がないものが多くあります。 また、余地は存分に作りつつも、使い手が自分自身の内面にどう適応していけば良いかがボヤけた可能性を感じられないものも多くあります。 僕は、これらはシンプルでないと思います。シンプルなものは、簡素であり、削ぎ落とされており、機能に注力しており、かつ可能性を感じれるものだと思います。

例えばWebサービスなどでよく「Simple and minimal User Interface」などの踊り文句をよく見ます。 確かにその製品はよく作られていて、チュートリアルなども充実していたりしますが、たいていの場合「余地」を感じません。 そこで言われる「シンプル」というのは、単に機能的な面で分かりやすいと言うだけで、言ってしまえば簡素なヘルメットであったり、トースターのような印象を受けます。 その製品を通して、新しい可能性や創造の余地、面白み、使うことを通して感じる「何か」が無いような印象を受けます。

そうなってしまう理由は、作り手の中で世界が完結しているからだと思います。その作り手の考える世界に準じること、準じさせることが製品の最大の目的になっているからです。 作り手にのみ主体があり、使い手は単なる使い手でしかないような製品です。 それは僕は、シンプルでないと思いますし、製品として僕の作りたいものではないなと思います。

「機能美」といってもその機能の先に「何か」を想像できるでしょうか。「シンプル」といって使い手の自由を奪うものではないでしょうか。作り手の世界を強要するものになっていないでしょうか。 まして、ユーザーの工夫や創造性を「そぐわないもの」として排除してはいけないと思います。作り手は場や空間、可能性を作るものであって、ユーザーの思想を脅かしてはいけないと思います。 新しい世界を作るのは作り手ではなく、それを使った使い手であるべきです （もちろんツールとして安全であるべきものや、規格に準ずるべきもの、業務的に正しく使わせることが目的のものは作り手の意図に従わせることが正しいと思います）。

僕が作りたい製品は、ミニマルで小さくて使い方がわかりやすいのはもちろん、使う人が自由に模索できる余地があるものを作りたいと思っています。 ただ挑戦的で尖ったものを作りたいという意味でなく、その人の中で製品を解釈できて、今までの（使い手の）常識を見返すキッカケになって、その人の人生にその人の工夫で取り込まれていくような製品です （もちろん美しい体験を保証したいので、導線や、ランディングページの分かりやすさは大切だと思っています）。

例えばモレスキンのノートはとても簡素でシンプルですが、それを使ってどうノートを取るか、人生を形作るかは使う人に委ねられています。 メモ帳のように使っても良いですし、バレットジャーナルのように使っても良いですし、ユビキタスキャプチャーのように使っても良いです。 その余地があるからこそモレスキンのノートはシンプルで簡素でありながら美しいですし、使い手に愛を与えるものだと思います。 それは使い手が自分で発掘した使い方そのものに愛を寄せているのだと思います。 モレスキンがすごいのは、シンプルなノートに「ピカソ」や「ゴッホ」も使っていたという物語を載せることで、その愛と可能性を加速させることにあると思います。 さらにすごいのは、ピカソやゴッホはモレスキン社のノートを使っていたわけではないという点ですね。

僕はPyQにおいては使い手が制限されないように最大限配慮して作りました。 PyQはWebの教育用プラットフォームですが、実務と同じ環境を動かしながら自学自習できることに力を使っています。 作り手としては教育用の制限された環境を提供するのが一番簡単です。利用者に、教育者が指示する方法でしか動けないようにするのが一番簡単です。 ですがそれでは意味が無いと考えています。PyQでは最大限シンプルに、本物の環境を提供しています。 さながら、机に向かう義務教育やテストでの評価を放棄して、文学や芸術、語学の実地を学生に体験させるようなものです。 これはセキュリティやシステムの設計、料金体系などを考えると本当にチャレンジングなことですが、僕も考えるシンプルさを貫けたかなと思っています。 今後、コンテンツも併せてよりユーザーさん自身が学ぶ場、工夫できる場、人生に可能性を感じれる場にしたいと思っています。

僕は、使い手の想像できる余地、新しい人生が想像できるワクワク、創意工夫できる自由がある製品を作りたいと思っています。 そういうものこそ、本当に人に愛され、長く、広く使われる製品なんじゃないかなと考えています。 新しい常識を、使う人自身が生み出して、その人自身の世界を変えていけるような製品を作りたいと思っています。

日本語アンチパターンその1「日本語ぶった切りプログラム」

伝わる日本語表現

ドキュメントやサポート、チャットでの説明で日本語を書く機会は多いと思います。 「プログラムについて日本語で伝える」ノウハウは、単に日本語の美しさだけではない部分もあるので難しい点です。

今日はその1つ、「日本語ぶった切りプログラム」というアンチパターンを見つけたので共有したいと思います。 アンチパターンとして名付けて、伝えやすく・覚えやすくしようという目論見です（今後の僕自身のためにも）。

アンチパターン:日本語ぶった切りプログラム

このアンチパターンは、日本語の文の途中にプログラムが入ってしまうアンチパターンです。 とくに「以下のように、」や「このような、」のあとにプログラムの引用を文中に書いてしまって、日本語が途中で切れてしまうものです。

以下がアンチパターンの例です

time_it 関数では以下のように、

def time_it():
    …
    …

関数の冒頭で処理を実行しています。

「以下のように、」の後にプログラムが貼られることで日本語が途中で切れてしまっています。 書き手の意図としては「この関数では以下のように〜『ここでプログラムを指差す』」というイメージはわかりますが、 読み手としてみるとプログラムのどこに集中して読めば良いのかが分かりにくくなります。

問題

以下のような問題が考えられます。

  • プログラムを読ませられる意図が事前に分からないので、どの点に注目して読めば良いのか分かりにくい
  • プログラムを読んでいる間にも、プログラム前に説明された日本語を記憶しておく必要があり疲れる

改善方法

プログラムを貼って説明したいこと・伝えたいことを、まず1文で表現してからコードを貼りましょう。

time_it 関数では以下のように、関数の冒頭で 〜 という処理を実行しています。

def time_it():
    …
    …

time_it 関数の冒頭で 〜 することによって、〜の意味があるためです。

* 〜するので、〜しやすい
* 〜するので、〜がわかりやすい

細かい説明や意図の説明は、プログラムを貼った後にすると良いと思います。 逆にプログラムの前に説明しすぎると、それはそれで前の文を覚えきれなくなってしまうので避けましょう。

アンチパターン名 日本語ぶった切りプログラム でした。

楽するための、日常動作のバッチ処理化

考え

どうも、こんにちは id:hirokiky です。

今日は日常生活する中で僕がやってみていることを話します。

完全に僕理論なので、「最近そんなことやってるんだ」くらいに楽に聞いてください。

習慣になると色々と楽

id:haruo860 さんと話していたときに、「習慣になってしまえば強い」という話題になりました。 何か動作をするときや決めるときに、習慣になっていれば迷いがなくて「楽」になる。 大切なことに集中できるので強いという話でした（だったと思いますが、あってますかね、はるおさん）。

そのとおりだなぁと僕も思っていて、例えば朝起きて出社することは大変です。 これは誰しもたぶんかなり辛いことだと思います。

「今日は遅刻しちゃおうかなぁ」「何着ようかなぁ」「顔は洗わなくていいかなぁ」と毎朝だらだらしてしまう。 でもそこが習慣になっていれば余計な考えなく済ませられます。 余計なエネルギーを使わずに超強大な定期タスク（朝出社するとか）をこなせるということです。

自分の中でココ最近試していた

僕なりにココ最近気をつけて実践していたことの話をします。 これは何かの本に書いてたことではなくて、単にここ数週間自分の中で試していることです。

「何かに影響されたんじゃないの？」ということは無いので安心してほしいのと、 実践するときも人には気づかれないように試せるので、「アレに影響されたんでしょ」と言われる心配もありません。

頭の中だけでやります

やりかたは簡単で、日常やる動作を頭の中で「まとめておく」ことです。 対象になるのは以下

  • 毎日やる動作
  • だらだらしてしまう動作

オススメは「朝起きた瞬間〜着替え終わるまで」です。

やることは3つだけです:

  • 頭の中で動作順の流れを決める
  • 全く同じように自動でやる
  • その動作中は他のことをしない

紙に順序を書き出したりはしません。 ポイントなのが 何をやるかでなく、どうやるか いかに 無思考で、自動で、意思決定なしに できるかが重要。

例えばここ数週間で確立した僕の「朝起きた瞬間からの動作」

  • 朝起きる
  • 顔を洗う
  • 歯を磨く
  • トイレに行く
  • 着替える

文字に列挙すると何ともないですが、決めておかないと日常どうしても「もうちょっと寝ようかなぁ」とか思ったりSNSをチラチラ見たりしてしまいます。 この「着替える」まではそういったことをせずに、機械的にやります。

僕の中では 日常動作のバッチ処理化 と呼んでいます。

各処理を意思決定なしにできることが大事

単一の処理、例えば「着替える」をとっても、自動でできるようにしておく必要があります（MUST）。

クローゼットの順番を整えておいて、何でもすぐ着れることだったり、服は着合わせしやすい服ばかり用意しておくとかです。 （例えば僕は着ない服をクローゼットから除外しました）。

バッチの設計は最小で

バッチ処理は短く終わるほうが良いですよね。

それと同じように日常動作のバッチ処理も短くしておきます。 例えば朝であればそれ以外の動作、ゴミ出ししたり、水槽の様子を見たりもありますが、 それはこのバッチが終わった後にやります。

ゴミ出しとかは曜日や時間という外部要因が関係して、かつ判断や分岐が必要になるのでバッチ処理からは除外したほうが良いです。 SNSやメールを見るのも、バッチ処理後にやったほうが良いです。

  • 日時、曜日
  • 判断が必要な動作、判断を迫られかねない動作
  • 他人、ペット
  • SNS、メール、Slack

こういった要因はバッチ処理の複雑化につながります。 とりあえず朝目が覚める〜朝出社するまでの最小構成（かつ気が重い場所）を、バッチを走らせるだけで完了するようにしておきます。 また外部要因にすぐ応えられるようにも、バッチは最小構成の設計にしましょう。

やろう！としないで良い

普段、自分がすでにやっている流れで、バッチとして意識するようにするだけで良いです。

色々試す中で、「化粧水をはたく」など「必須ではないがやっておきたい動作」を増やすと途端にやる気がなくなりました （いつもの朝起きられないモードに突入する）。除外をオススメします。

バッチは最小構成で、普段やっていることをまとめるだけで良いです。 その代わり、確実に自動でできるようにします。

バッチ化はどうでも良い意思決定の自動化

僕はもうずっと5年10年くらい朝食にカロリーメイトを食べてるんですが、これは「朝食が決まってないときはカロリーメイトとコーラ」と決めているからです。

とにかくどうでも良いことは事前に決まっていると色々楽だなぁと最近気づいて、ここ1ヶ月くらい自分で実験して日常動作のバッチ化をやってみています。

気持ち的な面が大きいですが、朝起きてからの流れが気楽になります。 ぜひ、ちょっと意識するだけで済むのでバッチ処理化をしてみてください。

まだ僕の勝手な理論でしかないので、実践してみた報告やコメントがアレば直接伝えるか、ブログに書いてみてください。

おまけで、意思決定についての考え

実家を離れたとき、何でも自分で決められることが本当に嬉しかったことを覚えています。 でもそれは逆に、自分で何でも決めないといけないということですよね。 僕の場合はそれは苦ではなかったんですが、ココ最近は色々と大事な意思決定が増えてきて、細かい日常の迷いみたいなのを無くしたいと思っていました。

例えば製品づくりやイベント開催などは意思決定が大事です。 やることとやらないこと、それを決めて線を引くこと、集中することが良い製品を作るのに大切です。 PyQ を作っていると、とくにそれを感じます（まぁ小さいチームだからというのもありますが）。

最近大事なことを考える時間と必要性が指数的に増えてきて、正直いうとココ数年は大変です。 なので日常の細かい迷いくらいは無くして、その瞬間くらいは脳みそを休ませてあげたいんですね。

何かを作るときは「人との調整」でなく「意思決定」することが大事だと思います。 とても大事なので、大変だからといってその機会を捨てる気はないです。 それ以外の余計な迷いはドンドン捨てていきたい、そんな今日この頃の、セキララトークでした。

他のオススメ記事

blog.hirokiky.org

Ubuntu17.10にしたら日本語が打てなくなった問題を何とか解決した話

Ubuntu 環境設定

f:id:hirokiky:20171021190512j:plain

雑メモです。

Ubuntu16.04からUbuntu17.10にアップグレードしたら日本語が打てなくなっちゃいました （まぁよくある話です）。

平たくいうと fcitx とIMの環境変数周りの設定がうまくいってなかったということで、色々場当たり的に直してたら動いて良かったという話です。

あんまりアテにならない情報です 間違ってたら教えてください。

まず「入力メソッド」 im-config で fcitx を設定するも状況改善せず。

im-config

GUIから設定して再起動するも変わりませんでした （単に im-config が設定している先のファイルを読んでないとか、 im-config が古いとかもありえます）。

とりあえず fcitx-diagnose で状態を確認。

fcitx-diagnose

以下の環境変数周りでエラーがでているようでした。

  • GTK_IM_MODULE
  • QT_IM_MODULE
  • XMODIFIERS

（間、 ibus をアンインストールしたりも試していました）

XMODIFIERSやQT_IM_MODULE環境変数の設定先

Ubuntu 17.10では /etc/environment に環境変数を設定しました。

export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"

Ubuntu17.10からWaylandで動いているそうで、 ~/.xprofile を読めないそう。 なので /etc/environment で設定しました（これって何かマズイとかありますかね。。？）。

とりあえず .xprofile とか .xinitrc とか .xinputrc とかに設定してみていましたがダメでした。

ArchWikiを参考に設定しました。

非デスクトップ環境

以下の行をデスクトップのスタートアップスクリプトファイル (GDM, LightDM, SDDM を使っている場合は .xprofile もしくは > .profile、startx や Slim を使っている場合は .xinitrc、Wayland を使っている場合は /etc/environment) に追加してくださ> い。この設定で、fcitx は gtk/qt のインプットメソッドモジュールを使うようになり xim プログラムをサポートします (必要なインプットメソッドモジュールがすでにインストールされているか確認してください)

まじっすかーということで、 /etc/environment に設定しました。

GNOME/Wayland 上での Fcitx の利用

Wayland は ~/.xprofile に保管された環境変数を読み込むことができないため、Wayland 上では Fcitx は正常に動作しません。Fcitx を利用するにはディスプレイマネージャから Xorg セッションを起動してください。

https://wiki.archlinux.jp/index.php/Fcitx

かなり場当たり的にですが、とりあえず解決して今も日本語を打てているという状態です。

僕のツイート

あとで見返して笑えそうなので残しておきます。

まとめ

ArchWiki日本語情報ほんとうにありがとうございます！ IMまわりとかは、英語での情報があんまり見つけられなかったので助かりました。

逆に今、消費的な趣味を大切にしてみる

考え

「趣味」という言葉に対してのハードルが日に日に強くなっていると感じませんか。

「このレベルでは趣味じゃないから」、「終わったら内容をまとめておかないと」、「まだここがコンプできてないな」など、 単に「趣味」と言ったときに付随する感情やレベル感、義務が大きくなっていると近ごろ自分の中に感じます。

もちろん頑張れることや何かを生み出すこと、達成することは素晴らしいことです。 ですけど最近は人生の99％がそういった頑張りの必要な時間になっている気がしているので、逆に、完全に消費的な趣味を考えてみました。

対象の人、対象でない人

最終的な目標や、生産的なこと、やりたいことはすでに持っている人と共有する考え方です。 「やってること多すぎてるかな。。。」「趣味へのハードルが高いなぁ」と思う・思ったことがある人です。

僕がまとめる内容はより生産的で健やかな人生を送るために書いています。 単に「何もしない優しい世界になろうよ」というつもりはありません。より生産的かつ心地良く生活や仕事をしたいという考えがまずあります。

静かな趣味

「消費的」というと語弊があるので、これからは「静かな趣味」と呼びます。 より生産的になれるように、あえて静かな趣味を考えてみます。

静かな趣味は完全に 静か でなくてはいけません。 趣味中にも頭の中で「ここまでやりたい」、「こうでなくては〜いけない」という考えは捨てるようにします。

静かな趣味では、以下のことを しません

  • No Goal: 目的を持たない
  • No Sharing: 共有しない（まとめない、アウトプットしない）
  • No Review: 批評しない（分析しない、コメントしない
  • No Agreement: 合意しない（一人でできる。社会に反しない）
  • No Planing: 計画をしない
  • No Choosing: 決断をしない（必要無い、少ない）

以下のことを します

  • 自分が気楽に楽しむ

自分が癒やされる、気楽になる、焦燥感がなくなるためにやります。

例えば私なりに、自分の好きなことで静かな趣味を考えてみました:

  • 音楽をただ聴く
    • とくにお気に入りのLinkinParkやGreenDay、BobDylanをただただ聴く
    • not「僕はロックが好きだから一通りのアーティストは聴いておこう」
    • not「ついでに英語の勉強にもなるかな、意味を調べよう」
  • 料理をする
    • 新しい料理でなく流れでできる煮物や炒め物をただ作って食べる
    • not「最高のチャーシューを作ってみたい」
    • not「米はミネラルウォーターで美味しさが変わる、どれが良いだろう」
  • 風呂に入る
    • 入浴剤を適当に入れてただ入る
    • 風呂あがりにホットアイマスクでもする
    • not「あそこの銭湯にも行ってみたかった。行ってみよう」
    • not「日本の名湯には一通り入っていないとね」
  • バイクでいつもの道を走る
    • 知ってる道をただ無意味に走る
    • not「友人とツーリングの計画をたてよう」
    • not「ヒザが擦れるようになりたい」
  • 知ってるゲームをする
    • 脳みそを動かさず、どこまでクリアしたいかも考えない
    • not「この新作をプレイして感想を書こう。ぜひプレイしておきたい」
    • not「スコアは3000以上いかないと、やったとは言えないだろう」
  • ペットをただ眺める
    • not「一通り飼育設備は揃えておきたい」

こうやってみると、自分が 趣味 としていることでも自分の中でのハードルが勝手に上がったりしていることに気づきます。 ささやかな瞬間にも頭の中の「頑張り」や「自己顕示」がでてくるので、それの無いようにします。

すでにある趣味でも「意識の高い」要素を抜いていくことで、気楽な趣味にできそうです。 僕はプログラミングが大好きですが、どうしても「目的」がついてくるので静かな趣味からは外しました。また、前提として前準備や注意点が多いツーリングなどもそもそも「静かな趣味」には向いてないようです。

「頑張り」を抜いて静かな趣味に変えるには、この辺りを意識してみるといいかもしれません:

  • 「コンプリート」をやめる
  • 「こういうものを作って便利にしたい」、「勝ちたい」、「今日はここまでいきたい」という目標をやめる
  • 「ちゃんと参加しないといけない」、「毎日続けよう」という義務感をやめる
  • 「こんなことやっています」、「新しいこの曲はここが最高なのでオススメです」などSNSへのシェアをやめる
  • 始めるまでの準備や調整がいることは一切やめる

この視点で考えるだけで気楽な趣味に変えられるんじゃないでしょうか。 せっかく見つけた自分の好きなことです。その好きなことに潰されないようにしたいものです。

まだ僕なりにも考えてみている段階ですので、間違っている点や他にも良い視点が今後でてくるかもしれません。 何かあれば、ぜひ教えてください。

心の疲れをとる技術という本にある「静のストレス解消法」

僕のお気に入りの本に「自衛隊メンタル教官が教える 心の疲れをとる技術」という本があります。 この本は、実際に自衛隊のコンバットストレス教官をしていた下園さんという方が、事故や災害、ショックな状況に対面する自衛官の心理的ケアに関わる中で培った方法論を紹介する本です。

「心の疲れをとる技術」でも「静」のストレス解消法を持つことが大切だと書かれています。

ポイントは、「動」と「静」のストレス解消法を持つことだ。特に「静」のストレス解消法を準備することを強調している。　エネルギーが低下している第２段階以降は、活発に活動する「動」のストレス解消法は、確かに快感も大きいかもしれないが、その活動のための疲労が大きく、結果的にムリが深まっていく。　例えば、疲れている人が、休日に趣味のサッカーをしたとしよう。その時は楽しいかもしれないが、次の日はもっと疲れている。　ドライブや海外旅行なども、かなりのエネルギーを使う。

「第2段階」というのはこの本で語られている心の疲れの3段階の2段階目ということです。

夜更かし系のストレス解消法も、第２段階以降はマイナスが大きくなる。アルコールが加われば、さらによくない（アルコールについては、後述）。　第２段階以降は、静のストレス解消法を選択するべきなのだ。　ヨガ、軽い散歩などは、疲労回復に効果があることが証明されている。　話をするという作業は、悩みの整理になるだけでなく、静のストレス解消法でもある。 （中略） 他にも、森林浴、庭いじり、俳句や短歌、囲碁や将棋などの頭脳ゲーム、読書、音楽（聞く、奏でる）、映画鑑賞、プラモデル作り、料理、日曜大工などの単純作業、何か作り出す作業などは、心に栄養を与える。　ただし、オンラインゲームやマージャンなどのギャンブルは、なかなか抜けにくいし、夜更かしになりがちだ。お金を使いすぎたりすると、後で自責感が大きくなるというマイナスも大きい。注意が必要だ。　このような、静のストレス解消法は、動のストレス解消法に比べて、瞬間的な快感が少ない。しかし、続けているうちにじわじわとその良さがわかってくる。　だからこそ、第２段階までの比較的元気な時に、「育てて」おかなければならないのだ。

あまり詳細に「静」のストレス解消法については書かれていませんが、イメージは静かな趣味かなと思います。 こちらの本も良い本ですので、「ケガした時の保険」的に読んでおくと良いと思います。

引用元: 「自衛隊メンタル教官が教える 心の疲れをとる技術 下園壮太」1章より

自衛隊メンタル教官が教える 心の疲れをとる技術

自衛隊メンタル教官が教える 心の疲れをとる技術

自分の趣味は何だっけ？どんな姿勢でやっていたっけ？

最近こそ「趣味」と言えるまでのハードルが高くなっている気がします。 SNSの普及で専門的なコミュニティに関わりやすくなったからでしょうか。より高い「趣味性」や「SNS映え」が大切になってきている気がします。 また「好き勝手なセリフや批評を控えて、正しい意見をやり取りすべきだよね」という良い流れも感じます。ですが逆説的に、好き勝手やれる・言える隙間が少なくなっているようにも思います。

今ある静かな趣味は何でしょうか。 単に好き勝手できて、誰にも言わない趣味。 少し気を抜いてできるものを考えてみるのはどうでしょう。

自分の好きにできる趣味なんだから、本当に何にもならなくても良いと思います。 そのリラックスできる時間で心身が回復して、頑張りたいときに頑張れるようにしておきたいです。

Pythonでできることは？何が作れるの？その疑問に答える本がPythonエンジニアファーストブック

f:id:hirokiky:20170929114020j:plain:w500

こんにちは、埼玉のジャックニコルソンです。 シャイニングのつもりがよくあるYouTuberっぽくなった画像がこちらです。

さて、Pythonエンジニアファーストブックが発売されました！

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

どんな本なの？と聞かれることがありますので、紹介します。

Pythonでできることは何？何か作ったこと、ありますか？

そんなことありますよね。僕もWebばかりだったので、つい1、2年前までPythonでのデータ分析は触ったことすらありませんでした。

一通りPythonでできること、作れるものを知っておきたくはないですか？

  • Pythonで何ができるかだいたい分かっている 。できないことも分かっている。
  • データ分析 や Webアプリの作り方 、 スクレイピングのやり方 など一通り知っていて、作ってみて動かしたことがある。

そうなれる本があります。 それが、Pythonエンジニアファーストブックです。

他の言語を知ってる人向けの本です

プログラミング自体全く全然分からない方、ごめんなさい 。この本は他のプログラミング言語をほんの少しでも知ってる人に向けた本です。

ですので、言語の説明やライブラリーのインストール方法などは必要最低限に絞っています。 逆に言うと、他言語を少しでも知っている、PCに慣れている人には簡潔で分かりやすい内容になっています。

そして、データ分析 や スクレイピング、 Webアプリ開発 や Pythonでのオススメ開発環境 などたくさんの内容が盛り込まれています。 もちろん、PythonのトレンドやPythonの基礎、インストールや導入方法、プログラミング開発の基本なども網羅されています。

初心者の人には説明が不十分の場合があるかもしれません。ですがその代わりに、この一冊でPythonの広い広い世界をぎゅっとまとめて体験できます。

（プログラミング自体分からない方が一通りPythonを勉強したいときは PyQ をオススメします）

自分で各ライブラリーを調べる必要がありません

この本にはPythonの基本はもちろん

  • Git
  • Pycharm
  • Sphinx
  • Pandas
  • JupyterNotebook
  • BeautifulSoup
  • Requests
  • Scrapy
  • Django

などが盛りだくさんで登場します。

もしそれらすべてを知ろうと思うと、インストール方法はもちろん、基本的な使い方やチュートリアルを調べるのは大変だとは思いませんか。 公式サイトやQiitaやブログを色々調べて、「これが良さそうかなぁ」という情報を探すのも大変です。

このPythonエンジニアファーストブックなら、それら すべてのインストール方法や基本的な使い方、実際の作り方が網羅されています 。

調査の時間で長いと1、2時間かかったりします。Pythonエンジニアファーストブック1冊分で、合計で10時間ほどの調査時間を短縮できるんじゃないでしょうか。

もちろん、この本を中心に分からない点は調べていただく必要があります。 ですが基本的な使い方をマスターしたうえで学んでいただくので、間違いなくその時間も短くて済みます。

スクレイピング、データ分析、Webアプリを作りながら学べます

さらに、本の中で一気通貫して 「レゴのサイトから情報を取って解析、Webで表示する」という課題を実際に作りながら学べます 。

プログラミングを学んでも身についていないということがありませんか？ 作りながら学べて、しかも一通り抑えておきたい分野の内容を身につけられたらすごいですよね。

Pythonエンジニアファーストブックなら実際に作りながら学べる ので、Pythonやライブラリーの要点を抑えつつシッカリ身につけられます。 また、勉強のために自分で課題設定をしたりアプリを設計する必要もありません。

さらになんと、 すべてのソースコードはGitHubで公開されています 。 正直これだけを参考にプログラムを読み進めてもかなり勉強になるんじゃないでしょうか。

github.com

もちろん本を買って勉強すれば効果や効率は高くなります。

未来のハッカーにもぜひ、体験いただけると嬉しいです。

要らない人には要らない本でしょう

言ってしまうと、Pythonでのスクレイピング、データ分析、Webについてよく知っている人には必要ない本でしょう。 また、全くのプログラミング初心者という方には厳しい内容だと思います。

ですので「ぜひどんな人でも買ってください」とはあんまり思いません。

ですが、 他のプログラミング言語をやってPythonに興味がある人 や、 Pythonを知っているけど知らない分野を体験したい人 にはオススメしたい一冊です。

前の版？全く違う本です

実は、この本は「Pythonエンジニア養成読本」という本を元に書かれた本です。購入いただいた方もいるかもしれません。 「同じ内容なら要らないかな」と思われるかもしれません。

ですがそれは違います。

こんな内容を学べます。

  • 1章 Pythonの動向
    • 最新のトレンドにアップデート
  • 2章 最低限知っておきたいPython言語の基本
    • 最新のPython3.6にアップデート。インストール方法も修正、言語の内容も追加修正
  • 3章 開発環境とチーム開発
    • 最新に各種アップデート。最新の仮想環境の作成方法など、ハマりどころも回避しています
  • 4章 スクレイピング
    • 完全書きおろし
    • 課題設定から アプリケーションまで新規に作っています
    • 「スクレイピングとは？」から学べます
  • 5章 PyData入門ガイド
    • 新規の課題に合わせて大幅修正、アップデート
    • 実際に4章で取得したデータからデータ分析を学べます
    • 販売されているレゴのデータから、ピース数と値段の回帰を求めたりできて面白いです！
  • 6章 Webアプリケーション開発
    • *完全書きおろし
    • 以前あったものはすべて捨てて、今回の課題に合わせてDjangoで書き直された大作です
    • Djangoアプリの設計から、DBの設計まで作っています
    • 取得したレゴデータを取り込んで、管理できるWebアプリを作れるようになります
    • 著者間のレビューで相当議論したので、かなり ノウハウが詰まったDjangoアプリと内容 になったと思います

内容からコンセプトなど全く新しい本となっています。

前回の「Pythonエンジニア養成読本」は、ムック本として全体をつまみ食いする雑誌的な面がありましたが、今回のPythonエンジニアファーストブックは本の体裁として大きく生まれ変わりました。

この本のお話をいただいとき、「本の改訂」という名目だったので気軽にやるかーと参加させていただきましたが、新しい本を作りあげる話だとは思いませんでした。。大変でした。。。ｗ

300ページを超える厚みです

300ページを超える、けっこうな厚みのある本です。 Pandas、Scrapy、Djangoを学ぶ内容についても、実際の課題に取り組みながらプログラムを作る濃い内容になっています。

f:id:hirokiky:20170929102522j:plain

しかも、Scrapyで取得したデータをPandasで操作したり、Djangoで表示したりと章の間で課題が一貫しているのでかなり楽しめる内容です。 また、本の中にあるプログラムはすべてGitHub公開されていますので、このプログラムを読むだけで十分勉強になるような内容です（もちろん、本を買って読めばさらに効果的かつ時短になります

300ページという厚みは、今、僕の家の中で探したものだと「サーバ/インフラを支える技術」と同じくらいの大きさ、厚さです （上の写真がそれです。サーバ/インフラを支える技術は昔僕がお世話になった本です）。

内容の十分さを感じてもらえるのではないでしょうか。

Kindle版で、今すぐ始められます

Pythonエンジニアファーストブックには Kindle版もあります ！

今すぐこの下のリンクから購入いただければ、今すぐ、Pythonの世界を歩み始められます。

他のプログラミング言語は知っているのにPythonは知らない、Pythonは知っているけど分野が限られてしまっているなという方、ぜひ、Pythonエンジニアファーストブックで作りながらPythonの広い世界を体験してください 。

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

Pythonって便利で楽しいな、こんなものも作れるんだ、と感じてもらえると嬉しいです。