このエントリーはフィヨルドブートキャンプ Part 2 Advent Calendar 2020の9日目の記事です。 プログラミングを始めるにはパソコンが必要ですがMacとかを用意するにはいきなり10万円以上のお金がかかってしまい敷居が高いです。そこで中古のパソコンとLinuxを使って1万円代で環境を用意しようというお話です。WebプログラマーはLinux知識が必須なのでこれを使えばLinux力養成（強制）ギプスとしても働くのでとてもいいです。 パソコン選び おすすめはThinkPadの中古専門店 Be-Stockで中古のThinkPad X230を買うことです。 大体14,000円ぐらいで売ってます。 Linuxをインストールするパソコンは安ければなんでもいいんですが、ThinkPadは中古市場に出物が多く安定して流通していること、Linuxをインストールして使う人が多いため情報が豊富な
プログラミングスクールのフィヨルドブートキャンプを運営していて、就職に関するアドバイスを求められることも多いです。SESについてはよく訊かれるのでここにまとめて回答しておきます。 SESとは SES(System Engineering Service)とはソフトウェア開発・運用・保守における委託契約の一種です。特定の業務に対してエンジニアを派遣し、エンジニアリングの能力を時間で提供します。 他に一般的な契約として請負契約があります。（特定派遣については2018年に廃止されました） この二つは主に報酬の対象が違います。 SES：労働時間に対して報酬を支払う。 請負：成果物に対して報酬を支払う。 SESはその時間働いていれば必ずお金がもらえますが、請負は成果物（システム）ができなかったら報酬が貰えません。 請負が成果物によって報酬が出るか決まるということは、「成果物とは何か？」ということを事
フィヨルドブートキャンプというプログラミングスクールのEラーニングアプリをCloud Run + Railsで動かしています。 1ヶ月使ってみた結果、8,000円ぐらいでした。 Cloud Runが300円でCloud SQLが7,000円って感じです。Cloud Buildとかちょこまかしたのはありますが誤差の範囲。 Cloud Runは1コンテナだったら1日10円ぐらいなんですよね。信じられないほど安い。 これでDockerイメージ放り込んでおけば自動スケールの環境が手に入るならほとんどの仕事のアプリはこれでいい気がします。パフォーマンスもいいし、これからのアプリは全部これで行こうと思います。
プログラミングスクール（フィヨルドブートキャンプ）で勉強している方へよくお話している内容なのでここに書いておきます。 わからない、ツラい プログラミング（に限らず新しいこと）を勉強してるときに、 「何がわからないのかもわからない。ツラい。」 ってときがあると思います。 わからなくて1日何も進まなかったらとてもツラいと思います。１週間何も進まなかったらもっとツラいと思います。 この「何がわからないのかもわからない」というやつ。これはすごくツラいですが、プログラマーにとっては非常によくある状態です。 全然気に病むことはないです。 「ドンマイ、ドンマイ、締まっていこうー！」 ぐらいの感じです。 日々新しい技術を覚える必要があるプログラマーには頻繁におきます。 プログラマーとして働いている人はこの状態のプロです。 むしろ「これが飯の種になる」と考えている節があります。 この状態からの抜け出し方を知
BasecampのHEYがリリースされましたね。 見れば見るほどBasecamp社のWebアプリの作り方をまとめた本であるGetting Realの内容に従って作られてるアプリだなとGetting RealをバイブルにしてWebアプリ作成を仕事にしてきた我々としては嬉しくなってしまいます。（2007年の本なのに！） ただ、業界内で「Getting Real良いですよね、私もすごく好きです。」という人は多いですが「え？あんたの作ってるアプリ全然Getting Real的じゃなくない？」ということがしばしばあります。 フィヨルドブートキャンプの最終課題の「自分で考えたWebサービスを作る」ではGetting Realを読んでからどういうサービスなのかを表現するエレベーターピッチを作ることになっています。 しかし「これってGetting Realに書いてあることと真逆じゃない？ホントに読んだ？」
プログラミングスクールのフィヨルドブートキャンプの提出物のレビューでよく指摘するシリーズ。 メソッド名に同じ名詞が頻出する場合、その名詞をクラス名として抜き出すとスッキリすることが多い。特にそれらのメソッドが同じインスタンス変数を使ってる場合は尚更。 Bad: class File attr_accessor :permission def open # ... end def check_permission # ... end def fetch_permission # ... end def permission_characters # ... end end Good: class File def open(path) # ... @permission = Permission.new(file) end end class Permission def initializ
（ハライチ感） Foo.configure do |config| config.name = "foo" config.email = "foo@example.com" end こっちでもかけたりする。 Foo.config.name = "foo" Foo.config.email = "foo@example.com" こういうやつ。 実装は大体こういう感じになってる。 module Foo class << self def configure yield config end def config @_config ||= Config.new end end class Config attr_accessor :name, :email def initialize @name = "no name" @email = "default@example.com" end e
プログラミングスクールのメンターが新MacBook Proがきたときやっている設定 - komagataのブログ
こんにちは、タイトルは昨今の流行を取り入れた自虐です😭 MacBook Pro 13inch 2020が来たので設定しつつ、いつもやっている設定を書きます。 キーボードや入力設定をする まずはこれ。 CapsLockをControlにする。 キーリピートを最速に、リピート入力認識を最短にする。 App Storeからアプリをインストール すでにインストールしてたやつをまた入れる。 CotEditor 使っているのを見つかると「老害だ〜！」と言われるんですがこっそり使ってます。 サブとして使うCotEditorの良さ Slack みんな大好き。 Simplenote 自分用のテキストはここに置いてます。 Kindle PCで使うことは意外と多い。 TweetDeck by Twitter こういうツールでホームのタイムラインは視界に入れないようにすると精神衛生上良い。 Xcode 一応。
フィヨルドブートキャンプというプログラミングスクールで初めてのPRに対するレビューをたくさんやっています。これらの指摘は世界中で行われていると思うので無駄が減るように書きました。 Files changedを確認したか 真っ先に注意したい点。 ローカルの自分のエディタ上で確認していたとしても、PRを作ったら必ずFiles changedを確認する癖をつけよう。GitHubのソースコードビューワーの機能で色々と気づける点もある。 明らかにFiles changedを一回も見てないなというPRはレビュワーもそれと分かります。 lintを通しているか rubyだったらrubocop、jsだったらeslint どういうルールが良いかという高度は話題は置いておいて、まずはlintを通しているか否か。 ファイルの末尾に改行があるか これ どのエディターでも設定で自動的に入るようにできるので設定すること
ボランティア開発者が「反乱」。もっとオープンソースに還元されるべき？（山口健太） - 個人 - Yahoo!ニュース これいろんな意見がありますよね。オープンソース・オープンソースコミュニティ大好きなので開発者・ユーザーにとって良い方向に進むといいなと思います。 それとは別に、オープンソース開発者の義務について思うこと。 OSSに好き勝手に要望を出すことは良いと思う。 「だったら自分でやれよ」って言っちゃうとフィードバックが無くなっちゃうので。 それと同時にOSSコミッターが持つ最大の権利が、 「要望を無視すること」 かな〜と思いました。（要望を「反論する」「却下する」ではなく「無視する」） 「好き勝手に要望を出すのはOK」ただしコミッタは「スルーする権利」を持つ。 好き勝手な要望に全部向き合わないといけないのではコミッターの体が持たないんじゃないかな〜と思います。 この「スルーする」って
フィヨルドブートキャンプでメンターとしてコードレビューをしています。自由な形式でプログラムを書く課題の場合、やはりオブジェクト指向プログラミングにみなさん苦戦しているようです。 特に、オブジェクト指向プログラミングのイメージが掴めないと、 「何をクラスメソッドにして何をインスタンスメソッドにすればいいのか」 がわかりません。（みんなここで詰まっている） なので、これを説明するのはものすごく難しいんですが、挑戦してみます。 （クラスを定義する記法や使い方はRuby超入門などで読んだという方を前提とします。） クラスとインスタンス クラス と インスタンス は 鋳型 と 実体 だと考えてください。 鋳型とはこういうやつです。 タイヤキの鋳型はタイヤキそのものとは別のものですが、その鋳型からできる全てのタイヤキの形を決めています。 Person（人）クラスで考えてみます。 Person（人）とい
Herokuミートアップ第0回〜第2回ぐらいにちょこちょこ登壇したり出席してるぐらいのHeroku好きな俺ですが、Herokuに月3万ぐらいかかってて、サービスには満足してるんですが、やっぱりTokyoリージョンじゃないと遅いのでAWSかGCPに移ろうかと検討してました。 最後にHeroku EnterpriseのPrivate Spacesを検討してみようとお問い合わせしてみました。 すると要するに最小プランでも月14万ぐらい + 現在のDyno料金アップ + 各種アドオン料金もアップということでした。（まずはお打ち合わせをなどのプレッシャーを回避しつつ聞いたところによると） おそらくTokyoリージョンが使いたいためだけに使うものじゃないんでしょうね。 GCP行きます…
フィヨルドブートキャンプの「自分で考えたWebサービスを作る」のカリキュラムでいつも言ってることまとめ。 「作ってみました」と「リリースしました」は違う 「作ってみました」と言うつもりで作ったWebサービスと「リリースしました」と言うつもりで作ったWebサービスは大きく違います。 「作ってみました」はお試し・実験のような意味合いで、自分の実力イコールではないことになります。下記のようないろいろな言い訳のできる余地がある言い方です。 技術の実験なのでデザインは本気ではない。 自分以外の誰かに使ってもらおうとは思ってない。 ターゲットは考えてない。 マネタイズは考えてない。 本気で作ってない。 それに対して「リリースしました」は下記のように色々と突っ込まれることが予想されるので、それに対して「現時点での全力である」と言えるように作ることになります。 「使いづらいんじゃない？」 「デザインがダサ
ここ最近で一番感動したサービスきました。（rono23に教わったサービス） ビデオ会議のブッキング面倒問題 コロナでビデオ会議が増えてます。でもビデオ会議のブッキングはクッソだるい。 「私達の可能な日時を調整して3つほど候補日をお伝えします。」（本当はもっと大丈夫な時間あるけどキリがないので3点だけ伝える） （社内の参加者で調整…） 08月3日(月) 10:00〜12:00、13:00〜15:00 08月5日(水) 13:00〜15:00 08月6日(木) 10:00〜12:00 上記いずれかでご都合の良い時間帯があればお知らせください。 「私どもも社内で調整して折り返します」 （お客さん側の参加者間で調整…） 08月5日(水) 13:00〜15:00 こちらでお願い致します。 では当日、宜しくお願い致します。 コレ。 何ターンもやりとりが発生してやってられない。 気軽にビデオ会議ができな
フィヨルドブートキャンプのrailsアプリをherokuからGCPのCloud Runに移行しました。 GCPに詳しい@bluerabbit777jpさんにやってもらいました。僕もこれを参考にしながら他のサービスも移行しようと思います。 この辺りのサービスの機能は日々進化してる感じなんですが、Cloud BuildのトリガーががGitHub Reposの特定のブランチにpushされたら動くというのに対応したので、masterにpushされたらCloud BuildでDocker ImageをビルドしてCloud Runにデプロイされるという感じです。 設定はちょっと面倒ですが、好きなDocker Imageをデプロイすればオートスケールってのは自由度が高くていいですね。 bootcampの規模では常に1インスタンスで夜中に1〜2回ぐらい0インスタンスになる感じです。0からの立ち上がりの初回
新型コロナウィルスの感染拡大により家で過ごすことが増えていると思います。フィヨルドブートキャンプでは、 「ちくしょう、勉強だ。」 キャンペーンの一環として、プログラマーのリモートワークはどうなっているのか、フィヨルドブートキャンプにゆかりのあるメンター、卒業生、プロのエンジニアの方々にリモートワークの状況や環境、コツなどをインタビューしていきたいと思います。 第1回目はまずはフィヨルドブートキャンプのメンターのkomagata氏にインタビューを行いました。 お名前・お仕事・フィヨルドブートキャンプとの関係を教えてください。 合同会社フィヨルドのプログラマーのkomagataです。Railsを使った受託開発やプログラミングスクールのフィヨルドブートキャンプのメンターをやっています。 ご自宅での作業環境を教えてください。 パソコン: Mac mini (Late 2014)、Windows 自
ずっと下記に書いたような問題意識を自分たちのプログラミングスクールに対して持っております。 OSS Gateオンラインワークショップに参加 - komagataのブログ そこでこんな活動をやってみたらどうかな〜と思っています。（スクール内限定じゃなくてパブリックなワークショップにしたい） OSS活動は終わらないネットゲームであり、みんな脳汁を垂れ流して楽しんでおります。しかしそこに辿り着くまでに色々と障壁があり、プログラミングに興味のある人や初心者の方にプログラミングの楽しさを知ってもらうためのワークショップができないかと考えております。（また、OSS活動以外のプログラミングの楽しみもいいと思う） Joy of Programming（プログラミングの楽しみ） １回につき１テーマのプログラミングの楽しみについて体験してもらい、みんなで楽しむ。 役に立つとか、勉強になるとかは置いておいて、楽
Komagata Maru 100 -
pakikipagkapwa tao – philippin news collections. Poster Making: Pagpapaunlad ng Continue Reading
bundle2.2からか対応platformが細かくなった。 arm64-darwin-22 arm64-darwin-23 x86_64-darwin-21 x86_64-darwin-22 x86_64-linux こんな感じでosのバージョン毎に追加してくのは辛い。みんなどうやってるのかなと思ってSlackのruby-jpのsupportチャンネルで質問させてもらいました。 gohさん、kojix2さんに教えていただきました。ありがとうございます。 結論から言うとこう言う感じで良さそう。 PLATFORMS universal-darwin x86_64-linux mac関連は全部universal-darwinでOK。CIや本番環境、WSL2の人用にはx86_64-linuxでOK。
プログラミングスクールのフィヨルドブートキャンプを運営しています。 プログラミングに限らずですが、メンターの役割の人が、 「生徒の人から質問がきた時になぜすぐに答えを即答してくれないのか」 について書きたいと思います。 質問している人にとっては、「なんですぐ答えを即答してくれないんだよ、ヒントとかいいからさ。ウゼェ〜」と思っちゃうかもしれません。 そこでプログラミングのバグを殺人事件、バグの原因を犯人に例えて書いてみたいと思います。 プログラムが動かない殺人事件 新米プログラマー「このプログラムが動きません、なぜでしょうか？」 新米捜査官「この殺人事件の犯人がわかりません、誰でしょうか？」 ベテランプログラマー「15行目のiの変数が原因ですよ。」 ベテラン刑事「吉田が犯人だ。」 〜次の事件〜 新米捜査官「この殺人事件の犯人がわかりません、誰でしょうか？」 ベテラン刑事「おい！毎回俺に犯人を
Remoでミートアップしてみた - komagataのブログ
プログラミングスクールのフィヨルドブートキャンプでは毎月オフラインでミートアップという名の飲み会イベントをやっていたんですが、コロナの影響でオンライでのミートアップに移行しました。そのオンラインミートアップにリモートカンファレンスサービスのRemoを使ってみました。 （イベント中の座席画像は撮り忘れたのでイベント終わった後の画像です） どんなツール？ Remoの特徴はテーブル毎に別れたビデオチャットルームがあり、Wクリックすることで自由にテーブルを移動するように他のルームに移動できるところです。 「あの人と話したいからあっちのテーブルに移ろう」 とか 「他の話題で話したいから別のテーブルに移ろう」 などができるってことですね。 1つの共通の大きなルームだけだと1つの話題しか話せないので全員参加の雑談はしづらいです。要は立食パーティーみたいなフリートークができます。 これが今まで立食で飲み食
PiroさんからITエンジニア1年生のためのまんがでわかるLinuxをご献本いただきました。ありがとうございます！ こちらは僕らがやっているフィヨルドブートキャンプでも参考書籍にさせていただいている「まんがでわかるLinux シス管系女子」にLinuxの本当の入門者用の内容を追加して新しくした感じの本になっています。（今から買うなら今回の新しい方一択です） 完全に「新人教育する人の目線」になっちゃうんですが、Linuxに入門する人にとってより入りやすくなっていて素晴らしかったです。 弊社スクールでもLinuxを入門するときに、 「Terminalをなぜ使うのかわからない」 「どういうシチュエーションでみんな使うのかわからない」 などイメージがしづらいという部分でつまづく人が多くいます。 新人が入社したところから仕事で必要になって一つづつ学んでいくというストーリーがまんがで描かれることによっ
mentionable gemで簡単にmentionが実装できます。（こういうやつ → @komagata） komagata/mentionable インストール gem 'mentionable' $ bundle install 使い方 app/models/comment.rb: class Comment mentionable_as :body def after_save_mention(new_mentions) p new_mentions # => ["@komagata", "@machida"] end end Commentモデルのbodyにmentionが含まれる文章が保存される場合、mentionable_asでそのカラムを指定したらデフォルトでafter_save_mentionメソッドが呼ばれるので実装して置けばOK。 そのカラムにメンションが含まれていた
公式ドキュメントにもしっかりあるし、みんなデフォルトでやってるかもしれないけど、すごく早くなったのでご紹介。 ビルドを高速化する際のおすすめの方法 | Cloud Build のドキュメント | Google Cloud 今まではCloud BuildでCloud Runにデプロイするときにでdockerイメージをbuildするところを下記のようにしてたんですが、 - id: Build name: gcr.io/cloud-builders/docker args: ['build', '-t', 'asia.gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA', '-t', 'asia.gcr.io/$PROJECT_ID/$REPO_NAME:latest', '.', '-f', 'Dockerfile'] そこの前に下記のように前回最後にb
フィヨルドトーーク！ - komagataのブログ
先日のフィヨルドブートキャンプのオンラインミートアップにフィヨルドトーーク！を初めて使ってみました。 フィヨルドトーーク！は以前フィヨルドブートキャンプにエンジニア研修で来られたGMOペパボの@akhtさんが卒業制作で作ったペパトーーク！（旧Super Cool Web App）を@akht_ikdさんの許可を得てforkして@komagataと@machidaがミートアップ用に改造したサービスです。（「誰に」という項目を追加してデザインを変えただけ） akht/super-cool-web-app: ランチで話すネタがない？そんなあなたにsuper-cool-web-app フィヨルドトーーク！はイベントの時のトークテーマを募集してランダムで表示するアプリです。 匿名で質問やトークテーマを応募できます。この画面を見ればなんとなくわかると思います。 事前に募集しておいたものからランダムで一
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1万円台で始めるプログラミング学習 - komagataのブログ
SES企業はやめた方がいいですか？ - komagataのブログ
RailsでCloud Runは1月いくらかかるか - komagataのブログ
わからないときの心持ちについて - komagataのブログ
Getting Real的なものとそうでないもの - komagataのブログ
[RubyTips] 頻出名詞をクラスに抜き出す - komagataのブログ
blockで設定するヤーツ - komagataのブログ
初心者がRailsプロジェクトへの初PRする前に見るチェックリスト - komagataのブログ
OSSコミッター最大の権利は「要望を無視する」こと - komagataのブログ
オブジェクト指向プログラミングの考え方 - komagataのブログ
Heroku Enterpriseは月14万以上かかる - komagataのブログ
「作ってみました」じゃなくて「リリースしました」と言おう - komagataのブログ
ビデオ会議開催がクッソ楽になるサービス - komagataのブログ
RailsアプリをHerokuからCloud Runに移行した - komagataのブログ
教えてリモートワーク komagataさんの場合 - Fjord, Inc(株式会社フィヨルド)
プログラミングの楽しみワークショップ - komagataのブログ
GemfileのPLATFORMSの書き方 - komagataのブログ
スクールのメンターがなぜすぐに答えを教えないか - komagataのブログ
ITエンジニア1年生のためのまんがでわかるLinux - komagataのブログ
mentionable gemでmentionを実装する - komagataのブログ
Cloud Buildのデプロイを高速化 - komagataのブログ