utamaro’s blog

誰かの役に立つ情報を発信するブログ

githubの寄付提供プログラムが始まった件について

はじめに

githubはご存知でしょうか。

アカウントは持っているのですが、私は使っていません。以前からprivateリポジトリの作成が無料なbitbacketを使ってます。 ブログの内容とか、一時的にpushしたいときに利用しています。

というのはどうでもよくて、以下サイトからGitHub Sponsorsが始まったことを知りました。

codezine.jp

これまでオープンソースでの開発は収益に繋がりにくく、エンジニアとしてのメリットは少なかったです。 あるとするなら、名声を得られるので就職やヘッドハンティングに利用されることでしょうか。

こちらのヘルプページによると、最初の1年間は手数料がかからずに寄付されたお金は全額手元に入るようです。

help.github.com

ただ、いつまでも手数料無料というわけでは無いので、どこかで数%の手数料を取られることでしょう。 何%とるのかはわからないのですが、システムを維持するためにはお金がかかるので必ず取られるでしょう。

開発者はどのように動くか

世の中の開発者がどのように動くのかはわからないので、自分ならどのように動くか考えてみます。

基本は以下のように進みます。

  1. 調査
  2. 行動
  3. 振り返り

調査

まず、寄付を得られるレベルはどのレベルなのかを調べます。 PR&Mergeしたからと言って寄付を得られるわけではないでしょう。 何度も何度も課題について向き合い、それを解決し続けることによって得られるものだと思います。

1,2回参加した人にお金を払おうと考える人はいないと思います。

そこで、1つのプロジェクトでどの程度参加すれば上位に食い込めるのかを調べます。 PRやIssueを何回も出している型で、有効な意見を出している方がどのくらい貢献しているのかを基準にします。

つまり、世間的に有用な人材がどのくらい活動しているのかを調べ、それに近い働きをします。 日になんどコミットして、issueをどのくらい解決していてなどなど。

ただ、これはとても大変な道のりだと考えています。

会社で働いている場合、一つの業務をやっていれば月数十万もらえます。 寄付の場合、複数のプロジェクトに参加して、それぞれ別の知識が必要で、寄付を得るには長期間やり続ける必要があります。

根性か、情熱がなければ続けられないものです。

行動

どのくらい貢献すればよいのか調査ができたら、今度はその仮説を基に行動します。

具体的には参加人数が少ないOSSに対して参加します。

おそらくそこでは寄付を得られないでしょう。

そこでは、どのように開発を行うのかを試すために参加します。 どのようにコードを書くのが良いのか、gitのcommitやPRはどのように出すのが良いかなど、知識として得ているモノを実践します。

大きなOSSでやってしまうと、流れを止めてしまったり他のエンジニアに対して迷惑をかけてしまうので小さなところでやります。 もちろん、小さなOSSで迷惑をかけていいわけでは無いのですが、何事にも練習というのは必要だということです。 他に練習できる場所があるのなら、そこでやるべきでしょう。

振り返り

調査して、行動したら振り返りをします。

この振り返りでは、自分が立てた仮説が正しかったのか考えます。 仮説が正しかったと判断するだけの情報が得られなかった場合、行動を続けます。

判断するだけの情報を得られた場合は、仮説が正しかったかどうかを考えます。 正しければそのまま行動を続けるか、さらに仮説を簡略化するか、効率化します。

間違っていると判断すれば、不足しているだろう情報を調査して、新たに仮説を立てます。

まとめ

私ならやらないだろうなと考えます。 収入を得るまでにやらなければならないことが多く、とてもつらい道のりだからです。

そんなことより、自分が欲しいサービスを作るとかしてその成果物をもとに就職します。 それだけで月数十万の収入を得られます。

お金を得るだけならこれが一番はやいし、簡単では無いでしょうか。

お金ではなく、OSSに貢献したいという意識があるというなら参加するのが良いと思います。

株式会社トランビが信金中央金庫グループとの業務提携が決定しました。

はじめに

株式会社トランビが信金中央金庫グループとの業務提携が決まりました。

株式会社トランビは後継者不足によって廃業される事業者がM&Aを行えるプラットフォーム「トランビ」を提供しています。

実際のプラットフォームへは以下のリンクからアクセスできるので、興味がある方はみてみてください。

www.tranbi.com

信金中央金庫グループについてですが、金融機関の一つです。 それ以上の情報を持っていないのでなんとも言えないのですが、潰れることは9割方ないといえます。

トランビはどうなるのか考えてみた。

以下のサイトを見ても何を提携するのかわからないので予想になります。

koenji.keizai.biz

トランビについては「はじめに」で書いたとおりでM&Aできるプラットフォームを提供しています。

信金中央金庫グループには「信金キャピタル株式会社」が含まれています。

この会社では「M&A仲介業務と投資育成業務」を行っています。

ここらへんが関係しているのではと考えています。

銀行というのは事業者に一番近い立ち位置を持っています。

というのも銀行業務の中には「投資」「融資」「出資」があります。 それぞれ金を貸すものですが、金を貸すのは銀行です。

金の貸し方についてはそれぞれ異なるのですが、事業者は銀行からお金を借りて事業を行います。

だいたいは金を返せなくなったり、負債をかかえて事業を継続できなくなった際に廃業します。

それを察知できるのはトランビよりも銀行側の方が直接事業者と接している分だけ早いと考えます。

いち早く察知した事業者に対して、トランビを活かしてM&Aの機会を提供するのだと思います。

と、ここまで書いていてSBIのまとめたページを見つけました。

www.sbigroup.co.jp

こちらのページには業務提携の背景等書かれています。参考にしてください。

一番心配していること

私の中では、「銀行が作るシステムは堅い」という考えがあります。 堅くするために新しい技術を利用せずに安定性や・安全性を重視して開発をしていると思います。

これにトランビが引っ張られた場合、機能の追加や修正など足を引っ張られるかもなと。

あまり詳しくないので、技術視点ではこのくらいしかわかりません。

もっと詳しいサイトや、考えを載せているサイトがあれば教えていただけると助かります。

ファーウェイが独自のOSを提供する?

はじめに

アメリカが華為技術(ファーウェイ)を本気で潰しにかかっていることはご存知だと思います。

世界市場的にはスマホで第2位を誇っており、中国市場でも大きなシェアを得ています。

規制によって何が起こるのかというと、アメリカにファーウェイ製品が入らないということ。

アメリカに入ってこないことによって、アメリカに本社を置くGoogleAndroidを提供しなくなること。

これはインバウンド規制によるものです。

この規制は外国企業の通信機器の仕様をやめさせるものです。

もしGoogleがファーウェイ製品に対して製品を提供した場合、この規制に従わないことになります。

国に逆らうことはできないので、Googleの行動は理解できます。

ファーウェイ独自OS?

こちらの記事を目にしました。

japanese.engadget.com

「はじめに」で書いたように、Androidはファーウェイに搭載されなくなります。

そうなった場合、日本や各国で取り扱っているファーウェイ製品にはAndroidが入っていません。

単純にOSが入っていないので、動かない文鎮と化します。

その対応策として、ファーウェイは独自のOSを利用可能になるようです。

当然でしょう。

独自OSを搭載した端末について

まだ詳しい情報は無いようです。

Androidとは異なるOSとのことなので、Androidに対応したアプリは動かないのではないでしょうか?

そうなった場合、開発者としてはそれに対応するメリットは無いように思える(利用者が減る可能性を考えて)ので、開発者は少ないでしょう。

僕も対応したくないです。

今でさえIOSAndroidで別れてるのに。。

それから、ブラウザはどうなるのでしょうか。

GoogleChromeは使えるのでしょうか。

独自のブラウザを使うとなれば厳しいですし、既存のブラウザを利用するのではと思います。

何にしてもファーウェイとしては独自のOSを出したとしてもシェアの低下は免れないでしょう。

Chromium版EdgeのmacOS版がリリースされました。

アメリカにあるMicrosoft社が5月20日macOSに対応したChromium版Edgeをリリースしました。

こちらのページでダウンロードもできます。 https://www.microsoftedgeinsider.com/en-us/?form=MO12FS&OCID=MO12FS

mac版のedgeが出てきたことによって何が起こるか

まず、利用者にとっては利用するブラウザは何でもよく、言ってしまえば検索ができれば問題ないでしょう。

問題となるのは、開発者にとってどうなるかです。

これまでフロントエンドの開発者が対応しなければならないブラウザが少なくとも5つありました。

  1. Google Chrome
  2. Firefox
  3. Microsoft Edge
  4. Internet Explorer 11
  5. Safari

これらのブラウザに対応するために多大な苦労がありました。 あるブラウザではバグがいつまでも残っていて、いつまでも対応し続けなければならなかったり。どのブラウザとは言いませんが、苦労がありました。

そこにmac版のEdgeが追加されます。

中身はChromiumで動いているのでスタイルはGoogle Cromeと同じように開発が可能でしょう。

ただし、mac版と言っていることから分かる通り、Touch Barに対応しています。

これによって、ブラウザ上での操作が可能で、もしかするとそれに対応する必要が出てくるのではないかと考えています。

例えば、Electronを利用したデスクトップアプリケーションではTouchBar Apiが提供されています。 https://electronjs.org/docs/api/touch-bar

これと同じように対応する必要が出てくるかもしれません。

(´・∀・`)

┐(´д`)┌

まぁ、頑張るしかないですよね。

現在のトレンドを比較してみました

Google Trendを利用してすべての国でフィルタリングしてトレンドを比較しました。

検索には以下の単語を利用しています。

  1. Google Chrome
  2. Firefox
  3. Edge
  4. IE
  5. Safari

f:id:miyaji-y26:20190522082634p:plain

それぞれの色に対応させるとこのようになります。

  1. Google Chrome (青)
  2. Firefox (赤)
  3. Edge (黄)
  4. IE (緑)
  5. Safari (紫)

結果を見ると、IEが一番低い値となっています。 順番にするとこのようになります。

  1. chrome
  2. edge
  3. Safari
  4. firefox
  5. IE

chromeが1番で、IEが最下位なのは予想通りですが、edgeが2番なのはびっくりしました。 別の単語での検索も入っているのでこれが正しいとは限りませんが、Chromium Edgeという検索が2050%上昇していたのがわかります。

f:id:miyaji-y26:20190522082855p:plain

世界的にも注目されているようです。

これからの動向にも注目したいです。

最後に

mac版でedgeを出してもChromiumベースなら、Google Chromeを使えばいいのでは?と思ってしまいます。

macにはSafariも入っていますし、わざわざ出す理由は無いと思うのですが。。。

macで利用可能なmicrosoft製ブラウザはなかったので出したのでしょうか。

これによって何が変わっていくのか。これからの動きに注目したいです。

エンジニアになるためには何をすればよいか

概要

プログラミングを勉強する場合どのように勉強すると良いか、自分の経験から記事にしました。 これから勉強する方の一つの道標として役立てればと思います。

※ この記事は過去ブログを作った際に載せていた内容を書き直しています。

最初に

この記事ではプログラミングを学ぼうと考えている人たちで、最初に「何から勉強すれば良いか」迷っている方の役に立てれたらと考えて書いています。 私自身のプログラミングを勉強してきた流れをもとにして、それを参考にしていただけたら幸いです。

少なくとも一人はこの方法でエンジニアになって、画像のようなブログを手作りできるぐらいにはなれると思います。
(維持コストがかかるのでブログは廃止しています。)

f:id:miyaji-y26:20190521210022p:plain

f:id:miyaji-y26:20190521210114p:plain

少々見苦しくあるのですが、このようなモノを作りました。

本題ですが、以下の流れでどのように勉強してきたのかを書いていきたいと思います。 1. 最初にプログラミングを勉強し始めたのは? 2. どのような勉強をしたのか 3. 次にやったこと 4. 社会に出てから 5. まとめ

最初にプログラミングを勉強し始めたのはいつ?

私が最初にプログラムに触ったのは大学1年の頃でした。

記事を書いている段階で25歳なので、今から7年ぐらい前の18歳ぐらいの頃です。

当時の私は高校のときにhtmlcssに触って、「わけわからん」と理解できずに手放したぐらいの知識量です。 おそらく、今始めて勉強を始めようと考えている方と同じぐらいの知識量と経験だと思います。

javajavascriptの違いがわからないぐらいのレベルと言えばわかるでしょうか?

始めたばかりの人は皆そのくらいです。

どのような勉強をしたのか

初めて触った言語は大学1年生のときに講義で勉強したjavaです。 そのときはjavaの基礎構文を勉強しました。

はっきり言ってしまえば、本の内容をそのままやるだけの講義でした。 本は「やさしいjava」シリーズを使って勉強していました。

初めてやることなので、全然わかりませんでした。 プログラムを上から下に読むということもわかっていないレベルです。(冗談抜きです)

for文がどのように動くのかわからなかったですし、以下のような2重のfor文なんて意味不明でした。 i++って何?とか聞いていたと思います。

for (var i = 0; i < 3; i++) {
    for (var j = 0; j < 3; j++) {
        System.out.println("i=" + i + ". j=" + j);
    }
}

その時、「わからないです」と聞いたら笑われたので自分で解決する癖がついたのだと思います。

そんな未熟者の私が一番つらかったことがあります。 講義の終わり頃に課題を出されて完成できなかった場合に帰れなかったことです。 あれはいい経験でした。

今になって思えば、エンジニアとしての本質なのでしょう。 社会でも締め切りが決められていて、それに遵守しなければならなくて、終わらないと帰れないですから。

次にやったこと

そこからは講義はほとんど変わりませんでした。

学ぶ言語がjavaからC言語に変わったり、javaを使ってコンパイラを作ったりと現状を考えるとなんの役にも立たない知識です。

こういったことを勉強して私が思ったことは「将来が詰む」です。

業務的な知識がなく、他と同じ知識量と未経験の若造ではどの企業にも雇ってもらえないと考えたからです。

なので最低でも自分自身で課題を解決することができ、なにか作って実績を作ろうと考えました。

まずは落ちものパズルの大定番である「テトリス」と「ぷよ○よ」作って、その後に「オセロ」を作りました。

これらで得られた経験は、htmlcssjavascriptを使ってアプリケーションを作れたということです。 サーバを絡めた経験はなかったのですが、「自分は作れる」という自信を得ることができました。

当時は同じような行動をしている人が周りにはいなくて、研究室に入ってから自分以上のレベルの人に会ってますます焦ったのを覚えています。

そこからは遊びに行くとかすることはなく、ひたすらプログラムを書いていました。

社会に出てから

大学時代にいくつかの実績を作って、それを面接時に見せるということをやっていたら入社できました。

早めに内定がでたので、そこで決めてのんびりしていたのを覚えています。

やはり、客観的にみてわかるだけの実績があるとわかりやすいのだと思います。 実績がない場合はコミュニケーション能力をアピールしたり、スケジュール管理ができるといったことをアピールすると良いでしょう。

業務を行うことになってから、社内のエンジニアとして課題解決を行っていました。 詳細は書けないのですが、「問題点」を挙げて、その「解決方法」を考えて、「実行」するという業務です。

最初は「勉強するため」や、「経験を得るため」という理由から働いていたのですが、今は違います。

会社で得られる経験なんて、たかが知れています。 得られるのものは「人脈」と「給料」です。

なにか実装したりすれば、その実装についての知識は得られるでしょうが、それは個人でやっても同じです。 むしろ、個人でやったほうが最初から最後までできるのですべての経験を得られるでしょう。

まとめ

エンジニアになった流れは、その他多くの方と同じだと思います。

なんの特徴も無いのですが、私の場合は以下の流れでエンジニアになりました。 1. 大学に入る 2. javaを勉強する 3. C言語を勉強する 4. ひたすら勉強して目に見える実績を作る

このとき、プログラミングスクールとか行かなかったですし、人に聞いたときに笑われた経験から自分で解決していました。 個人的には高いスクール料を払うより、公式ドキュメントを読んだり、お金を出してノウハウ買うのが良いと思います。

61.DjangoBasicAppsのCommentsを読んでみる

urls.pyには目新しいものがなかったのでスルーします。

urlを使ってbooksと同じように作成されていたのでスルーします。

1つだけわかったことは、viewの引数にはviews.py内のメソッドを入れるということ。

views.pyを確認する

コメント時の日付をバリデーションする方法を見つけました。

get_object_or_404というショートカットが用意されていることにも気が付きました。

このショートカットは便利そうですね。request.userは認証していない場合にNoneになるはずですから、404になる。

djangorestframeworkを使う場合は、serializerを使ったり、IsAuthenticatedを使うことで対応ができると思います。

認証に関しても

DELTA = datetime.datetime.now() - datetime.timedelta(
    minutes=getattr(settings, 'COMMENT_ALTERATION_TIME_LIMIT', 15)
)


def comment_edit(request, object_id, template_name='comments/edit.html'):
    comment = get_object_or_404(Comment, pk=object_id, user=request.user)

    if DELTA > comment.submit_date:
         return comment_error(request)

フォームを使ったバリデーションです。

if request.method == 'POST':
    form = CommentForm(request.POST, instance=comment)
    if form.is_valid():
        form.save()
        return redirect(request, comment.content_object)

CommentFormは↓のようになっています

class CommentForm(ModelForm):
    class Meta:
        model = Comment
        exclude = ('content_type', 'object_pk', 'site', 'user', 'is_public',
            'user_name', 'user_email', 'user_url', 'submit_date', 'ip_address',
            'is_removed',)

個人的には、formは最終的に見た目をカスタマイズすることになるので、Formからタグは作成しないようにしています。

バリデーション目的のみ使うのが良いと思います。

バリデーションのみ行う場合、↓cerberusというライブラリがあるので参考にしてみてください。

http://docs.python-cerberus.org/en/stable/

load i18nという翻訳tag

template内に↓のような記述がありました。

{% load i18n %}

このタグを使うと、翻訳タグを使うことができます。

{% trans "Text" %}

実際に使う際は↓のドキュメントを参考にするとよい

https://docs.djangoproject.com/ja/2.1/topics/i18n/translation/#how-django-discovers-language-preference

60.DjangoBasicAppsという数年前のプロジェクトのBooksを読んでみる

DjangoBasicAppsのリポジトリは↓です。

https://github.com/nathanborror/django-basic-apps

その中にあるBooksを読んで、Djangoの書き方を確認したいと思いました。

https://github.com/nathanborror/django-basic-apps/tree/master/basic/books

views.pyが見当たらない

見当たらないです。

views.pyが見つからないとか…なんででしょうか。

views.pyがないので、urls.pyを確認してみる

object_detailというのがどこにあるのかみつかりませんでした。

url(r'^genres/(?P<slug>[-\w]+)/$',
    view='object_detail',
    kwargs=genre_list,
    name='book_genre_detail',
),

genre_list自体は↓のように作成されていた。

genre_list = {
    'queryset': Genre.objects.all(),
}

この書き方はあまり使わないですね。

これだとページング処理が入らないし、データを固定にするならtemplateにそのまま書いてもよいです。

views.pyがないので拡張しづらいですね。

それから、as_viewがなくてなぜ大丈夫なのかわかりません。

templateを確認する

templateの書き方を見れるのは嬉しいですね。

これまでどうやって書けばよいのか手探りだったのでわかった気がします。

baseとなるtemplateは↓です。

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">

<html lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <title>{% block title %}{% endblock %}</title>
</head>
<body id="{% block body_id %}{% endblock %}" class="{% block body_class %}{% endblock %}">
  <div id="body">
    {% block body %}
        <div class="content_title">
            {% block content_title %}{% endblock %}
        </div>
        <div class="content">
            {% block content %}{% endblock %}
        </div>
    {% endblock %}
  </div>
</body>
</html>

blockは4つ定義されています。

  • title
  • body
    • content_title
    • content

bookのbaseは↓です

{% extends "base.html" %}
{% block body_class %}books{% endblock %}

book_list.htmlは↓です

{% extends "books/base_books.html" %}


{% block title %}Books{% endblock %}


{% block content_title %}
  <h2>Books</h2>
  {% include "books/_nav.html" %}
{% endblock %}


{% block content %}
    <table class="book_table">
        <tr>
            <th>Title</th>
            <th>Authors</th>
            <th>Progress</th>
        </tr>
    {% for book in object_list %}
        <tr>
            <td class="title"><a href="{{ book.get_absolute_url }}">{{ book.title }}{% if book.prefix %}, {{ book.prefix }}{% endif %}</a></td>
            <td class="authors">{% for author in book.authors.all %}<a href="{{ author.get_absolute_url }}">{{ author.full_name }}</a>{% if not forloop.last %}, {% endif %}{% endfor %}</td>
            <td class="publisher"><a href="{{ book.publisher.get_absolute_url }}">{{ book.publisher.full_title }}</a></td>
        </tr>
    {% endfor %}
    </table>
{% endblock %}

content_titleの中にincludeがあります。

includeが使えるのは初めて知りました。

jinja2でもincludeを使えるので当たり前といえば当たり前なんですが。。。

_nav.htmlは↓のようになっていました。

<div id="section_nav">
    <ul>
        <li class="music"><a href="{% url music_index %}">Music</a></li>
        <li class="movies"><a href="{% url movie_list %}">Movies</a></li>
        <li class="books"><a href="{% url book_list %}">Books</a>
            <ul>
                <li class="genres"><a href="{% url book_genre_list %}">Genres</a></li>
                <li class="publishers"><a href="{% url book_publisher_list %}">Publishers</a></li>
            </ul>
        </li>
    </ul>
</div>

階層構造でtemplateを表現するとこのようになります。

  • base.html
    • book_list.html
      • _nav.html

こうやって見るとずいぶんと効率的に書けるとわかります。

ただし、htmlのデザインを書いて、共通化できる箇所を考え、コーディングする技術が必要です。

頻繁にデザインが変わる際は共通化せずに実装し、最終的にリファクタリングする段階で共通化するのが良いでしょう。

headやfooter部分、ナビゲーション部分を共通化するのが良いと思いました。