おれ、エンジニアになるよ。

エンジニア志望の大学生がISUCON7出場を目指す成長日記

R.I.P.マギー, Welcome ディックス

こんばんは。

本日2度目の投稿ですwww

 

突然ではありますが、早速メンバーの入れ替え事案が発生しました。

 

マギー、逝く

 

 

タイトルの通り、マギーが逝きました。

 

「逝った」と言っても、彼は死んだわけではありませんwww

やりたいことがあるんだと。

 

 

 

f:id:matsuda-juri:20170504201914p:plain

 

 

まぁ、こういうことですwww

 

あ、やりたいことってのはラーメン屋じゃなくて、もっと大っきくて壮大なことらしいです。

我々としても彼のやりたいことはできるだけ応援したい。

 

君の分まで頑張るからね。

R.I.P. マギー。

 

 

さて、1人いなくなってしまった。

どうする。

 

ようこそディックス

 

 

なんてことはございません。

マギー脱退が決定して数秒後の様子がこちらです。

 

f:id:matsuda-juri:20170504202705p:plain

 

はい、即確保wwwwwwwwwwwww

その名もディックス

 

由来は...はい、「dick」からきてますwwwwwww

 

 

f:id:matsuda-juri:20170504203628j:plain

 

「正真正銘のディックス」

 

彼はこのTシャツを着てきましたwwwwwwwww

 

実はディックス、マサの高校の後輩なんですよ。

あと色々話聞いてると、すでに大学の単位150ぐらい取ってるとか、エストニア留学するために休学中とか、パソコン教室通ってるとか。

色々と活動的な面白いやつです。 

 

ってことでディックスを迎え入れました!

すでに正式メンバーとして、着々と課題をこなしています。

 

 

そしてチーム名も決まりました。

 

その名も

 

 

「仕事ください」

 

 

ww

 

新体制となったチーム「仕事ください」

みなさまにはどうかまた、温かく見守っていただけるとありがたいです。

よろしくお願い申し上げます。

 

 

 

 

 

・ディックス

yuki-f-oki.hatenablog.com

 

「Webを支える技術」を読んで 〜HTTPの基本〜

こんにちは。

世間はGWですが、人権のないぼくにそんなものはありませんww

ここ最近滞っていたアウトプットを一気にしたいと思います。

あと、メンバーの小ネタも別記事で書いていこうかなと.....wwww

 

 

では、いきまぁっぁあぁぁす!!!!

 

 

 

前回は「URI」のお話でした。

今回からはwebを支える技術の3本柱の1つ、「HTTP」についてまとめます。

 

 

HTTPの基本

 

 

「HTTPはTCP/IPをベースとしたプロトコル

 

ここで1冊目の「プロになるためのWeb技術入門」をおさらいすると、

TCP/IPは郵便屋さんの役割やったね。

情報をパケットという単位に分けて送受信しているんやった。

 

ここら辺の話をもうちょっと詳しくすると、インターネットのネットワークプロトコルは階層型になってるそうな。

んで、その階層ごとに担当するプロトコルがある。

 

どういうことかと言うと

 

・アプリケーション層

→ HTTP、NTP、SSHSMTPDNS

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

トランスポート層

→ UDPTCP

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

・インターネット層

→ IP

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

・ネットワークインターフェース層

→ イーサネット

 

IPが担当するのは下から2番目の「インターネット層」。

ここでは、パケットという単位に分割してデータを実際にやりとりするんや。 

 ちなみにこいつは「データを送り出すだけ」しかやらないらしいwww

 

そしてTCP 。

こいつはその上の「トランスポート層」を担当。

ここでは、IPが送り出したデータをTCPが転送する。

 

TCPでは接続先の相手に対してコネクションを張る。

このコネクションを使ってデータの抜け漏れをチェックしているんや。

んで、接続したコネクションで転送するデータが、どのアプリケーションに渡るかを決定するのがポート番号 。

ちなみにHTTPは80番やったね。

 

 

ここまでまとめると、

 

①インターネット層でIPがデータをトランスポート層に送り出す、

トランスポート層に渡ってきたデータを、TCPがポート番号で指定されたアプリケーションに転送する

 

こうやね。

 

 

HTTPの仕組み

 

基本的な仕組みは、「クライアント/サーバ」。

クライアントが出したリクエストをサーバで処理してレスポンスを返すというもの 。

 

この時、クライアントがやっているのは、

 

・リクエストメッセージの構築

・リクエストメッセージの送信

・(レスポンスが返るまでの待機)

・レスポンスメッセージの受信

・レスポンスメッセージの解析

・クライアントの目的を達成するために必要な処理

 

めっちゃ色々やっとるやんw

 

 

んで、同じくサーバがやっているのは、

 

・(リクエストの待機)

・リクエストメッセージの受信

・リクエストメッセージの解析

・適切なアプリケーションプログラムへの処理の委譲

・アプリケーションプログラムから結果を取得

・レスポンスメッセージの構築

・レスポンスメッセージの送信

 

 

 

HTTPの性質

 

HTTPの重要な性質の「ステートフル性」。

Cookieとかセッション状態とか出てきたけどもうちょっと詳しく。

 

ハンバーガーショップの例。

 

・ステートフルなやりとり

店員:「いらっしゃいませ。ご注文は?」

マサ:「セブバーガーセットで。」

店員:「サイドメニューは?」

マサ:「ポテト」

店員:「ドリンクは?」

〜〜〜〜省略〜〜〜〜

店員:「以上でよろしいですか?」

マサ:「はい。」

店員:「かしこまりました。」

 

.....うん、普通やねwww

ぼくらの日常会話はステートフルな会話ってことやな。

んじゃ、ステートレスなやりとりとは?

 

・ステートレスなやりとり

店員:「いらっしゃいませ。ご注文は?」

マサ:「セブバーガーセットで。」

店員:「サイドメニューは?」

マサ:「セブバーガーセットをポテトで。」

店員:「ドリンクは?」

マサ:「セブバーガーセットをポテトとコーラで。」

 〜〜〜〜〜〜〜〜〜〜〜省略〜〜〜〜〜〜〜〜〜〜〜

 

!?、マサがめんどくさい&ラリってるwwww

なるほど、ステートレスなやりとりってのは、毎回全ての注文を繰り返さないといけないわけやな。

一方のステートフルなやりとりでは、店員が毎回の注文を覚えているんやね。

 

このやりとりはweb上だと、クライアント(マサ)/サーバ(店員)になる。

一見ステートフルなやりとりの方がイケてるように見えるが、実はそうでないらしい。

 

ステートフルの欠点は、クライアントが増えるにしたがって、サーバが毎回のリクエストを覚えることが難しくなってくる。

 

ステートレスはこの点を解消している。

最終的なリクエストは、「セブバーガーセットのポテトとコーラ」

それまでのやりとりをサーバが忘れていても、リクエストメッセージにこれがあれば、サーバはちゃんと認識してくれるってわけやね。

 

けど、ステートレスにも欠点がある。

それは、いちいちリクエストを送らなければならないので

「送信するデータが多くなる」。

 

これはパフォーマンス低下につながる。

 

まとめると、

 

ステートレスなアーキテクチャはスケーラビティの面でめっちゃ優秀だけど、パフォーマンス低下の欠点もある。

 

ってことやな。

 

次回は「HTTPのメソッド」について。

ではでは、今日はこの辺で。

「Webを支える技術」を読んで 〜URI〜

こんにちは。

今日は「URI」の話。

ではガシガシ書いていきます。

 

 

URIとは

Uniform Resource Identifier

 

「リソースを統一的に識別するID」

 

これがあることによって、web上に存在するリソースを一意(それだけって意味)に示せるってわけ。

住所みたいなもんやね。

 

まぁ、「URL」と同じですわww

 

 

URIの構造

 

これも以前やりましたね。

けどもう一回おさらい。

 

URIスキーム:http

URIスキームは利用するプロトコルを表す。

上の場合は、

「httpでアクセスしますよー」

ってこと。

 

 

・ホスト名:dirty.jp

ここは必ず一意になる。

 

 

・パス:/unko/1

パスは階層を表す。

ホスト内で必ず一意になる。

 

 

URIの設計

 

どうやら「クールなURI」とやらがあるらしい。

URIをかっこよくしてどうすんねん。

 

ってことで「クールなURI」の定義は、

 

「変わらないURI

 

どういうことかと言うと、昔のURIはコロコロ変わっていたらしい。

「お気に入り」に入れてたwebサイトがある日突然見れなくなるみたいな。

「404 Not Found」とか出たら、たしかに萎えるよね。

 

そこで、変わらないURIこそが最上のURIということになった。

その最上でクールなポイントがこれ。

 

プログラミング言語に依存した拡張子やパスを含まない 

「.rb」とか「.php」とか入れちゃダメよ。

「/cgi-bin」もダメ。CGIの時代なんかとっくに終わったんだからぁぁ。

 

 

・メソッド名やセッションIDを含めない

例えば、「showPage」というメソッド名がURIに入っていると、リファクタリングしてメソッド名が変わったときにURIも変わっちゃうから。

そしてセッションIDと言えばCookieだけど、ログイン毎にURIが変わっちゃうことはもう想像がつく。(このぼくでもww)

そんなのクールじゃないっ!!

 

リファクタリング

プログラムの外部仕様(入力と出力)を変えずに、内部構造を安全に改善すること。

プログラムを理解しやすくするために、拡張性や再利用性を高めるわけやな。

要は、

「こまめに手入れしてプログラムを長持ちさせよう」

ってこと。

 

 

URIはリソースを表現する名詞にする

ユーザが分かるように何をする場所なのかがわかりやすくしましょう、ってことやね。

 

ログイン画面なら、dirty.jp/login

編集画面なら、dirty.jp/edit

 

みたいな。

 

 

URIを変更したいとき

 

でも、どうしてもURI変更しなくちゃいけないときってあるよね。

システム総入れ替えとかハードウェアの老朽化とかで。

そういうときは、「リダイレクト」っていう便利な方法がある。

 

リダイレクトとは、古いURIを新しいURIに転送するHTTPの仕組みのこと。

今回、その方法は割愛するけど、一応そういうもんがあるって覚えておこう。

 

 

よし、今日はここまで。

ではでは、この辺で。

 

 

 

 

「Webを支える技術」を読んで 〜アーキテクチャスタイルREST〜

こんにちは。

今日から3冊目に突入です。

 

昨日まで読んでいた「サーバ/インフラエンジニア養成読本」ですが、文字でまとめきれなくて記事にするのを断念しましたwwww

 

改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)

改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)

 

 

なんとなく「こんな感じ」っていうイメージはできたのでまぁいいかなww

割と用語とかコマンドの使い方が多かったので、今後もリファレンス用に使っていきやす!

そして今回からはこちら。

 

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

 

 

1冊目に読んだ「プロになるためのWeb技術入門」をより詳しく説明したものみたい。

 

では、やっていきますぞい。

 

Webを支える技術

 

そもそもの話。

webを支える技術は主に3つあるんや。

 

HTTP, URI, HTML

 

URI(unform resource identifier)を使えば、世界中の情報指し示すことができる。

HTMLはそれらの情報を表現する文書のフォーマット。

そして、HTTPというプロトコル(取り決め)を使って、それらの情報を取得したり発注したりするわけ。

 

この3つの技術を使えばシステムが動くわけなんだけど、これを実現するには中身の設計思想が必要になった。

 

その設計思想の1つがREST。

 

 

 

アーキテクチャスタイル

 

「RESTとはアーキテクチャスタイルである。」

 

はて?

 

アーキテクチャとは、複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す」

 

うん、どうやらアーキテクチャスタイルとアーキテクチャとは別物らしい。

例をあげると、

 

アーキテクチャスタイル:REST, P2P, MVC

 

アーキテクチャ:ブラウザ、サーバ、プロキシ、HTTP、URI、HTML

 

実装:Apache, Firefox, IE

 

 

そういえば、MVC(model-view-controller)もこの1つだっけ。

 

つまり、システム作るときにはただ闇雲に作るのではなく、ちゃんとこういうパターンで作ってね、ってことやね。

 

実は「クライアント/サーバ」もアーキテクチャスタイル。

RESTはこの「クライアント/サーバ」から派生しているんやって。

 

んじゃRESTって何??

 

 

 

 REST

Representational State Transfer

 

先にも説明したけど、もうちょい詳しく言うと、

 

「RESTは複数のアーキテクチャスタイルを組み合わせて構築した複合アーキテクチャスタイル」

 

なるほど。

んじゃ、それぞれのアーキテクチャって何なん??

 

・クライアント/サーバ

 => ユーザインタフェースと処理を分離する

 

 

・ステートレスサーバ

 => サーバ側でアプリケーション状態を持たない

 

「クライアント/サーバ」に最初に追加するアーキテクチャスタイル。

アプリケーション状態とはセッション状態のこと。

ログインからログアウトまでの一連の流れをセッションと呼ぶんやったね。

 

そうなると出てくるのが「Cookie」。

こいつはステートフルなやつ。

REST的に考えると、Cookieを使うのは間違ってるんやけど、フォーム認証行うのにCookieやめるわけにはいかないからしゃーないwww

まぁ、こういうこともあるよね。

 

 

・キャッシュ

 => クライアントとサーバの通信回数と量を減らす

 

一度取得したリソースをクライアント側で使い回す。

これによって、サーバとクライアント間での通信回数が減らすことができるんや。

けど、古いキャッシュを使っていると情報の信憑性が下がるから要注意。

 

 

・統一インターフェース

 => インターフェースを固定する

 

URIで指定したリソースに対する操作を、統一した限定的なインターフェースでやりましょう、ってこと。

 

 

・階層化システム

 => システム階層に分離する

 

サーバ/クライアント間には、ロードバランサを設置して負荷分散したり、プロキシを設置してアクセス制限したりする。

 

 

・コードオンデマンド

 => プログラムをクライアントにダウンロードして実行する

 

プログラムをサーバからダウンロードし、クライアント側でそれ実行する。

JSとかFlashがそう。

 

 

これら6つのアーキテクチャスタイルを組み合わせたのがRESTってわけやな。

細かいとこは実際に触りながら覚えていくとしよう。

 

では、今日はここまで。

 

「サーバ/インフラエンジニア養成読本」を読んで 〜SSHでCentOSにログイン〜

こんばんは。

今回は、よく使われる「SSHでログイン」について。

 

........??(はい出たー、ナニソレ的なやつー)

 

 

まずは前回したサーバOSの話をちょこっと。

 

matsuda-juri.hatenablog.com

 

実は、サーバOSは直接サーバ本体を操作しなくてもイジイジできちゃうらしい。

1台のPCに仮想環境を用意して、その上でサーバOSを動かすんや。

 

 

.......??(仮想環境ってなんや)

 

 

超簡単に言うと、1台のPCにもう1台PC作っちゃおう的な。

このもう1台のPCが仮想環境で、使うには仮想化ソフトウェアを導入する必要があるみたい。

Oracle VM VirtualBoxとか。

無償だし情報もいっぱいあるしね。

 

話を戻すと、このVirtualBoxCentOSを入れたらもう1台のPC完成ってわけ。

 

 

 

よし、SSHでログインしてみよう!

 

SSH

secure shell

 

SSHとは暗号化された通信で、ネットワークを介してリモートアクセスするのに使うんやって。

暗号化されてるから安全な通信が可能らしい。頼もしいね。

 

 

SSHを利用するにはSSHサーバが動作していることが条件。

この設定の話はちょっと今回割愛でwww

 

サーバがあるってことはクライアントよねー。

ってことでSSHクライアントが必要になるわけやね。

 

代表的なのがこれら。

 

・Tera Termttssh2.osdn.jp

 

PuTTY

http://www.chiark.greenend.org.uk/~sgtatham/putty/

 

Macターミナル

 

 

これらはターミナルエミュレーターって言うらしい。

 

ちなみに、

ぼくはこのターミナルエミュレーターって言葉知らなくて、

 

「このコマンドどこで打ちゃいいんだぁぁぁぁぁっぁぁっぁ」

 

ってなったことがありますwwww

 

まぁまぁそこは置いといて。

実際にTera Termを使う場合どうやるか?

 

Tera  Termでサーバにアクセスするには、

サーバのホスト名IPアドレスが必要になる。

 

 

.......ごめん。

もう気付いてるかもしれないけど、文字だけじゃ説明しにくいwwwwwww

 

 

ってことで最後にもう1回「SSHでログイン」のおさらい。

 

ぼく(クライアント):「マササーバにログインしまーす!!」

マサ(サーバ):「ホストの指定は.....うん、合ってるね。パスワードもOK! ようこそ

         マサワールドへ!!」

 

こんな感じwwwww

 

では、今日はこの辺で。

「サーバ/インフラエンジニア養成読本」を読んで 〜新人エンジニアのための基礎講座〜

こんばんは。

昨日まで就活で東京に来ておりました。

突然ですが、ぼくの就活スタイルはズバリ、

 

「スーツ絶対着ない!」www

 

 

もちろん、今回行ってきた4社とも私服で参加しました。

この私服only主義がモロに出たのが、1社目。

私服参加OKのとこだったので問題はありませんが、見事にぼくだけ私服。

 

ちょー気まずかったwww

 

しかし、ここで怖気付かない。

堂々と一番前の席に座ってやりましたよww

 

1次選考も無事に通過したので結果オーライです。

 

 

 

さて、今日からこのブログでまとめる本は、

「サーバ/インフラエンジニア養成読本」

 

改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)

改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)

 

 

ちょっと難しそう。

でも頑張るよし!!

 

 

WindowsLinuxの違い

 

みなさんの初めてのPCは何でしたか??

ちなみにぼくはMicrosoftSurface Pro2でした。

 

そんなSurfaceシリーズのOSはWindows

 

Windows

 

Windows OSの一番の特徴は、

 

GUIが整備されている

 

ということ。

 

GUIとは、Graphical User Interface

簡単に言うと、マウス操作を基本としたグラフィカルな画面でわかりやすく情報のやりとりができる。

 

また、エディタで設定ファイルを書く必要がないから、設定に自信がない人には使いやすらしい。

 

けど、複数のサーバにちょこっと(または同じ)設定をする場合は、サーバごとにラインセンス費用がかかってしまうのがちょっとめんどいところ。

 

Linux

 

そもそも「Linux」って言葉、聞き慣れないよね。

そもそものそもそも、よく耳にする「windows」とか「mac」ってのはOSのことを言ってるんやね。

windowsが入ってるPC」って言うでしょ?

 

このLinuxも同じOSのことなんだけど、無料なのだ。(商用の場合はライセンス費用がかかる)

ちなみに、

 

無料Linux

・Cent OS

Fedora

Ubuntu

など

 

有料Linux

Red Hat

SUSE

など

 

 

話を戻すと、Linuxの一番の特徴は、

 

CUIが整備されている

 

ということ。

 

CUIとは、Character User Interface

 

テキストベースで基本操作するので、自動化が簡単で、大量のサーバを管理する場合は圧倒的にLinuxの方が楽らしい。

 

黒画面に緑文字で、英語がガァーっと並んでるのイメージすると分かりやすいかな。

 

また、GUIがない分メモリを無駄に消費せず、高速な処理と、サーバの性能を最大限に使い切ることが実現できるんやって。

 

 

ミドルウェア

 

これはOSとアプリケーション実行環境の間に入って、動作を仲立ちしてくれるソフトウェアのこと。

実はここ、過去記事で書いたおかみさんとか職人さんのことを言うんよね。

 

その記事がこれ↓

matsuda-juri.hatenablog.com

 

 簡単にミドルウェア名を紹介しておくと、

 

Webサーバ(おかみさん)

→ Apache , Nginx , IIS

 

Appサーバ(職人さん)

→ Tomcat , JBoss , Unicorn , Gunicorn

 

DBサーバ(素材屋さん)

→ Oracle , PostgreSQL , MySQL , SQLserver , DB2

 

これら3つまとめてミドルウェア

今後超使うからこの言葉は覚えておこう。

 

 

キリがいいので今回はここまで。

次回は「仮想環境・Cent OS」からやっていきます。

 

 

 

そもそもなんでお前ISUCON出んの?

こんばんは。

本日2度目の投稿ですww

 

1冊目終わりちょうどキリがいいので、ここらでISUCON出場のきっかけや関係者について書いていこうかなと。

 

 

ISUCON出場のきっかけ

 

ちょうど2週間前。

とあるプロジェクトで一緒に開発していて、色々教えてくれる先輩エンジニアのさぼさんって方がいてですね。

 

さぼさん:「ISUCON出たら就職できるよ?ww」

ぼく:「は、はい......。(イスコンってなんだ?むしろ美味そうじゃないか!!)」

 

こうなったわけですよww

ちょうどその頃のぼくはと言うと、就活真っ最中で、渋谷ヒカリエにオフィスがある会社に落ちたとこだったんですねー。

就活振り出しになったぼくは、会社選びについてさぼさんに相談していたところ、さっきの会話になったというわけですw

 

そもそもですが。

ISUCONってのは競技プログラミングの大会で、毎年9月にLINE本社で行われます。

予選・本戦があって、本戦に勝ち進んでくる人たちはいわゆる「ハイパーなエンジニア」と呼ばれる方たちです。

しかしこの人たちは「一般枠」。

実は「学生枠」ってのもあるんですね。

 

どうやらさぼさんがおっしゃるには、予選までの半年間、基礎からみっちり勉強すればこの「学生枠」での本戦出場は可能であると。

しかもさぼさん自らがコーチングしてくれると。

 

ぼく:「はい、やります!」

 

ちょー単純wwwwww

 

こうしてさぼさんをコーチにお迎えして、ぼくのISUCON出場向けての成長物語が始まったわけです。

 

 

 

ぼくと心中してくれる2人の仲間

 

こうしてISUCONを目指すことが決まったわけですが、早速問題が。

1人では出場できないのですwww

 

ってことで仲間集めから。

このときぼくの頭にはとある1人が浮かび上がりました。

 

ちょくちょくこのブログでも登場する「マサ」ですwwwwwwww

 

間髪入れずにマサに連絡。

 

f:id:matsuda-juri:20170417190536p:plain

 

このあとめっちゃ煽りましたw

多分彼は今まででとてつもない煽りを受けたことでしょうwww

(ごめんねマサw)

そんなこんなして

 

f:id:matsuda-juri:20170417190804p:plain

 

 

マサ、鼻血プシャーー!!!

 

ぼくはその時思いましたね。

「一人目確保」。

 

その後日、マサさぼさんと会って色々説明を受けて、正式に仲間になりましたwwww

 

 

問題はあと1人。

結構デキる学生エンジニアを口説きにいきますが、ぼくらの実力を値踏みしてか、口説き失敗に終わりました.......。

 

まずい。あと1人......。

 

とりあえず2人でスタートし、ISUCON出場への第一課題。

 

さぼさん:「よし、まずはMac買おう。」

ぼくマサ:「了解です!」

 

こうして8ギガのi7Macを買って第一課題クリアwwww

 

そうこうしてるうちにコンサル会社のインターンシップが。

そこである一人の男と出会う。

 

Youtuberのマギー

 

一時期Youtubeで稼いでたらしいww

 

そんなマギーとぼくはインターンで一緒のグループになり、突然

 

マギー:「プログラミング好きなんです。学部も情報工に変えました。」

ぼく:「お、おう.....。(なんやこいつ。告白する相手間違っとるやろ。)」

 

あんまりに突然だったのでぼくは思考停止状態。

そして我に返った時、ピンときた。

 

ぼく;「(こいつも道連れや)」

 

マギーにISUCONのこと話すが、彼は自信なさげww

どうにかこうにか口説く(煽るww)が、最後の「Yes」が出てこない。

ここで最終手段。

 

ぼく:「とりあえずさぼさんに会ってみたら?」

 

すると

 

マギー:「じゃあ、やります!」

 

こうしてぼくと心中してくれる2人目の仲間が加わったのですwww

 

 

フリーランス学生のぼく、セブんちゅのマサ、そしてYoutuberのマギー

先輩エンジニアのさぼさんの指導の下、精一杯やっていきますのでどうか温かく見守っていただけるとありがたいです。

 

 

 

人物紹介

 

・さぼさん

saboyutaka.hatenablog.com

 

 

 ・マサ

masa-world.hateblo.jp

 

 

・マギー

twitter.com