サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
レイングッズ
qiita.com/jabba
開設して3週間ほどで収益10万円を個人開発サイトから得たので、そこでやったことを全部ここに公開する。 世の中には**億ドルのバリュエーションを獲得したスゲー起業家の話か、個人開発サイトを立ち上げたものの収益なんてゼロに近い話かの両極端しか無いように感じる。 パッと立ち上げてだいたい1ヶ月でiPhoneXが買えるぐらいのサイト規模というのは、どんなレベルのエンジニアでも手が届く範囲内にあるのが実感だ。「人生賭けて起業!」とかそんな熱い話ではない。普段の仕事が終わったら、ちょこちょこコードかいて個人的にアプリを公開して収益を得る、ぐらいの話。「1億総クリエイター時代」ではこんなやり方が世の流れに合っている気がする。 この記事でも「エンジニアはアウトプット至上主義であるべき」と主張している。自分で主張するからにはやっぱり得たノウハウは全部公開するのは当然だな、と。だいたい数週間で収益が10万円な
サイト名は「 mobet(モベット)」モは目標の「も」。ベットは「賭ける=懸ける」のbet。ドメインは語呂がよさげなので.gq(ジーキュー)にした。 お金を懸けた目標はやる気100倍 mobet(モベット.gq) 未達成の時だけ罰金が徴収される仕組み ダイエット、語学習得、筋トレ、なんかは最初は「やるぞー」となっても3日坊主で終わるのが誰にでもある。そういう時はこのモベットに目標と懸けるお金を登録する。例えばこんなの。 目標の設定 ポイントは「不二子さんはダイエット目標に1000円を懸けて誓ってる」ところ。 で、期限日の12月31日までダイエットをがんばっていただく。 期限日が来ると。。。 期限日になると登録時に設定した判定者に向けてメールが送信される。判定者は友人とか家族とか、まー自分自身でもいいんだけど。例でいくとメールの内容はこんな感じ。 不二子のお母さまへ 今日がおたく不二子のダイ
英語でよくある、いいこと言ってそうに見えるけどなんかプッとくる名言みたいなのが好きで集めていた。職場での息抜きにそういう一文をslackに貼り付けるのはよくやっていて、面白いからまとめてウェブサイトにした。 エンジニアの名言メーゲン https://www.meigen.ga/ バックグラウンドにきれいな景色の写真を入れて無駄に「いいこと言ってそう」な雰囲気にした。 名言は人気順ということでツイート数順に上から並べている。もし気に入ったのがあって、ツイッターで共有していただければ順位が上がりますよ、と。 無料だから.gaでドメインを取った。「名言. ガー」とでも覚えてください。 https://www.meigen.ga/ ボタンひとつで英語版に切り替わるので英語の勉強にもどうぞ。(学習効果の保証は一切無し) ほんとただの趣味でしかないんだけど、集めているのでもし面白いのをご存知でしたらサ
映画の辛口レビューと感想を機械学習を使ってブログ記事から集めてウェブサイトにした。名前はホット チリ レビューズ。 現在は約3万件のレビュー記事と6千本の映画が収録されている。最終的には機械学習の精度を高めてレビューを集めまくって世界一の映画ブログ総合サイトにするつもり。 映画の感想と辛口レビューをブログから集計 ホット チリ レビューズ ウェブスクレイピング + 機械学習 + ビッグデータ = なんかスゲーもの 3つの要素を足すと個人が立ち上げるウェブサイトであっても、すごいことができるはずという確信がある。機械学習はまだまだ学習中ではあるが成果が出てきたのでサイトを公開した。 映画レビューについて わりと映画のレビュー好きである。単なる映画好きとはちょっと異なる。あくまで「映画のレビュー」好き。 映画のレビューはそれだけで十分に楽しめるコンテンツになっている。必ずしも「レビューを読むこ
QiitaのAPIから投稿記事を取り出し、技術書籍を紹介している箇所を集計して、ランキングサイトを作った。作った本人が言うのも何だけど、できあがった技術書ランキングがやたらエンジニア指向で便利で面白いなー、と。 技術書ランキングをQiita記事の集計から作成した テック・ブック・ランク エンジニアにとって技術書の選定はまーまー苦労する。単なる発行部数ランキングでは「人気あるからって技術書として参考になるとはかぎらない」と、なってしまいがち。ブログでオススメされている書評なんかも参考にするが、結局それらは書評を書いた人の主観で書かれたのであって客観的指標にはなりえない。 そこで「Qiitaにある技術ブログ記事内で紹介されている書籍情報を集計すればひと味違った書籍ランキングになるのでは?」と考えた。 で、以下の条件に当てはまる本を「いい本」とした たくさんのQiita記事で紹介されている本 人
GraphQLをサーバー側とクライアント側とで実装してみて得た意識すべきポイント3つについて。 ひとつのエンドポイント バージョン無し できるだけ薄く この3つを意識して実装するのとそれが無いのとでは実装スピードが何倍か違うと思う。特にREST脳な人の場合。 GraphQLは使い所さえあえばめちゃくちゃに有用で面白い。しかもGraphQLの公式サイトはとてもわかりやすく説明されている。その辺のブログ記事よりもよほど洗練されていて、技術に関してはここ以外に読む必要はほぼ無い。 しかしGraphQLを使いはじめた当初はなんか妙にコーディングが進まなかった所があった。その原因はずっとRESTfulでやってきたREST脳の意識からGraphQLへと変換できていなかったことだった。GraphQLとRESTは設計思想が異なるので、意識を変える必要がある。その意識さえ変えればGraphQLに難しいところ
GraphQLは実装内容に合えばタイタニックの救命ボードのように混沌から救い出してくれる。だからと言って全てのプロジェクトがタイタニックな訳ではないので、使い所が合わなければそんな救命ボードにもあまり意味は無い、という話。 先日、個人開発して公開したプロジェクト「node-node-node」のバックエンドはRails APIにGraphQLを使っていて、このプロジェクト内容に対しては最高の親和性を発揮してくれた。 GraphQLのメリットを一言で言えば「クライアント=サーバー間での複雑なトランザクション処理の全てをGraphQLが吸収してくれる」ということに尽きる。ややこしい技術の詳細を書いたところでメリットはこれ以外に無い。 /usersや/postsというそれぞれのエンドポイントにリクエストを投げていたのがRESTful。 GraphQLにするとエンドポイントを気にすることなく「これ
この記事はかつての私と同じように「Reduxを使った非同期処理がいまいち分かんねー」という方に向けて書いた。とりあえずはReactの公式サイト、Reduxの公式サイト、Dan氏のReduxビデオ解説を観たが、なんかスッキリしない。特にReduxの非同期処理が分からない、という方向けの超シンプル解説。 Reactは公式サイトのチュートリアルなんかも充実していて丁寧だし分かりやすかった。しかしReduxは違う。特に公式サイトの非同期処理の例が変にややこしい。 こういうことをブログで書くと「アタシは公式サイトの説明を読んでも分からないバカです」と言ってるみたいだから、恥ずかしいしあまり書かれない。ウザいぐらいに「Reduxは素晴らしい。シンプル。カンタン」という発言がネット上にあふれている。 しかし私の頭ではパっと分からなかった。私以外でも「これ難しいなー」と思ってる人が居るんじゃないだろうか。
Chef client-serverモデルの入門者向け解説。 いまだになぜなのかはよく分からないが、Chef-soloや Knife-soloの解説はよくあるのにChef client-server版の解説があまり見当たらない。英語で検索すればたくさんヒットするし、英語圏でChefはclient-server版が主流に感じる。実際、私の今の勤め先であるベルリンのスタートアップでもそんな何千何万のサーバ数ではなく、小規模な数のサーバ数だがChefはclient-server版を利用している。 日本語情報でChef-soloが主流なのは最初に誰かが日本語でChef-soloを解説して、そこから派生して誰もがそれに沿って環境を構築しているうちに日本語のノウハウがSoloばっかりに溜まって、どんどんそっちに行ってしまったのかもしれない。日本語書籍にしても決まったようにSoloばかり。なんかもったい
open-uriってちゃんと実装しないとなにかと危険な香りがしますな、という話。 Ruby 2.4.0 リファレンスマニュアル module OpenURI 例えば外部のAPIを叩く必要があって として使っていたとする。 フォームから受け取ったパラメータを入れてopen(なんやら)とする場合、そのままなんでもopen()の中に入れるとかなり危険。 例えばこれはフォームに入れたURLにしたがって、そのウェブサイトに行ってなんか取ってくる例。 コードで言うとこんな感じ。 require "open-air" class PagesController < ApplicationController def search @page = open(search_params[:url]) end private def search_params params.permit(:url) end
まず以下にあるのがイケてないコード。一応動くし、テストもパスしている。でもそのコード品質は平均よりちょっと下という設定。 【範囲を指定してその期間の売上総合計を出すコード】 class OrdersReport def initialize(orders, start_date, end_date) @orders = orders @start_date = start_date @end_date = end_date end def total_sales_within_date_range orders_within_range = [] @orders.each do |order| if order.placed_at >= @start_date && order.placed_at <= @end_date orders_within_range << order end
ここで言う「Railsの中身のコード」というのはRailsを使ったRailsアプリのコードではない。Railsそのもののコード。DHHが書いたRailsのコード。$ rails new AppNameとかのコマンドが動く仕組みが書かれたコードのこと。 これって職場の同僚と英語で話しててもいっつもゴチャゴチャと説明が要る。RailsアプリのコードとRailsの中身のコードを区別してそれが一発で分かってもらえる表現があったら教えて欲しい。 いいコードのコードリーディングはオススメ ご存知のようにそのRailsの中身のコードというのが巨大でなかなかにレベルが高い。初心者では読むのも一苦労でそこが遠ざけてしまう原因にもなっている。それでも優れたコードをコードリーディングすることはいい勉強になるのでオススメ。 いかにコードリーディングが重要かは、いろんなブログなんかで優秀なエンジニアの方々が再三強調
海外転職の技術面談の形式に関してはこちらのブログに何度か書いたので、今回はその具体的な対策を書いた。ずばり「RubyとRailsに関する英語の基礎質問と解答例」 書類選考をみごとに通過したら次は電話面談かもしくはオフィスでの面談になる。いづれにしても採用側の会社からはエンジニアが2,3人ぐらい出てきて応募者の相手をすることになる。最初は本当に基礎的な技術質問から入る。それは誰にでも分かるような質問と答えで応募者に話してもらって緊張をほぐす意味と、あともうひとつは「箸にも棒にもかからない人に早々とご退場」願うためだ。あくまでメインは技術質問ではなくコーディングインタビューの方。 なんにしても技術質問の時点で詰まってはいけない。そんなに難しいことでもないし、技術分野に合わせて聞かれる内容はほぼ同じなので十分に対策が取れる。英語がネイティブじゃない応募者が詰まる原因とその対策は以下の3つの順にな
Googleの2段階認証の数字を出すのにいちいちiPhone取り出すのがいつも面倒だったのでMacのターミナルに入れた。これでコマンド一発で認証が完了するのでとても快適。 このアイコンのアプリをiPhoneとかのスマフォに入れて、起動したら出てくる数字を入れるのが通常のやり方。 それをターミナルのコマンドでポンと数字だす方法。こんな風に。
英語を使って海外のエンジニア職に転職しようとする際に避けては通れないのが技術面談。もし海外のエンジニア職への挑戦をお考えの方でそれが初めての場合、この技術面談の対策は十分にとっておいた方がいい。 きっと思っているよりも実際にやるとその難しさを実感するパターンがこの技術面談。たまにYouTubeに技術面談をシミュレーションしている様子のビデオが上がっているが、なんか嘘くさいし、そんなビデオを横から見ても一体ナニをどうすればいいのか対策の立てようがない。 だいたいこの技術面談でその応募者の相手をするのは現役バリバリのエンジニアだ。日本のように転職面接に人事の人が出てくることはまずない。エンジニアの技術レベルを測れるのはエンジニアだけ、という当たり前な理由なんだけど。とにかく現役のエンジニアがこれでもか、というぐらいにあなたの真の実力を読み取ろうとしてくる。 技術面談で出される問題は大きく分けて
TensorFlowはGoogleがオープンソースとして公開した機械学習のライブラリ。 www.tensorflow.org ここしばらく機械学習の本読んで、TensorFlow触りまくって出した結論はこれ。 TensorFlowは機械学習の初心者がスグにカンタンに使えるモノではない TensorFlowを使えば機械学習の概念をそのまま直感的にコードに落としこむことができる。ただ、そのためには機械学習の理論を予め知っておくことが必要。「ニューラル・ネットワーク」とか「構造パターンマイニング」とかの用語が分からないといちいちそこで手を止めて、調べる必要が出てくる。 ただ数学好きであれば、全てが数式で表現される世界が妙に楽しい。アルゴリズムや使い方さえ分かれば、かなりのレベルで面白いモノが実装できることは確かだ。 TensorFlowのインストール(MacOS編) まーここ見てインストールして
毎年スタックオーバーフローから世界中のITエンジニアを調査対象とした調査結果が出る。基本は英語圏のエンジニアに向けた調査になっているので、日本のエンジニアの現状とを比較する際にはとても参考になる。 人気のテクノロジー この手の調査結果ではいつもJavaScriptが1番。Javaも常に高順位にいる。PHPが5位の25.9%と意外にまだまだ人気な様子。 嫌いなテクノロジー 好きなテクノロジーの次のタブがこの嫌いなのランキング。トップ2がVisual BasicとWordPress。個人的にもこの2つにはあまり関わりたくない、という思いがある。 エンジニアの年齢 若い。。。中央値は27歳。27過ぎたらもう老人扱い。 エンジニアの皆さん、年食ったらフサフサな髪のズラかぶって、エステ行ってシワのばして若いフリしましょう。辛いですが、そういう世界らしいです。 どっちが好き?スターウォーズ VS スタ
世界の凄腕エンジニア、科学者が講演や本で語ったプログラミングに関する言葉を集めた、「凄腕エンジニアのお言葉集」は不思議にココロを打つのでまとめた。 たった一言でもその言葉を発するまでに作ってきたすごい製品や打ち出したすごい理論の上にある、と思うとなにかずっしりとその言葉の重みを感じる。 シンプルな方がいいんだよ Simpler is usually better - Rich Hickey Rich HickeyはClojure作った人、そうそうシンプルがいいんですよ。分かってはいるんだけど、なんかいつの間にか複雑なコードになってしまってるのが悩み。 小利口な奴になるな。自分を賢くみせようとして複雑なコードを書かないこと。シンプル、明確、再利用可能なコードを書くこと。シンプルに明確に普遍的に考えること。 Don't be clever. Don't try to write complic
めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね?という話。 ここで言う「ハマる」とはなにかに夢中になって没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。 先日、ハマった問題が解決した時の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが!」という前任者への怒りが混ざった状態だった。 サイトのSSLの有効期限切れが2週間後にせまっていた。やる事は証明書の更新、新しい証明書をAWSのELBに入れること。ただこれだけ。しかしハマった。どうやってもELBから「あなたのキーは無効です」みたいなエラーメッセージが返ってきた。2年前にSSLを設定したエンジニアは退職してしまって、もう居ない。その前任者とほぼ同じことをすればOkなはずなのに、なぜかできなかった。
公開鍵暗号の仕組みをまとめることにした。 先日作成して公開したエンジニア向けのパズル8は公開鍵暗号の仕組みを使っている。RSA暗号のコード書いてデバッグして、暗号の仕組みをかなり理解したので、せっかくだからまとめた。 金庫の中にに大事なモノを保管する時、まずは金庫を閉めて鍵をかける。すると鍵を持っている人にしか開けられなくなる。これが通常の鍵の仕組み。 ただネットを介した通信での暗号方式では少し事情が異なる。 まず送信者が金庫を閉めて鍵を使って鍵をかける。そしてそれを受信者に届ける際には金庫と鍵を送ってもらう必要がある。しかし金庫と鍵を同時に送るのは危険。途中でその鍵が見られたりコピーされたりしたら、金庫に入れる(暗号化すること)意味が無くなってしまうからだ。大事なモノに鍵をかけて送るのに、その鍵を送る方法が無防備だとまったく無意味になってしまう。 そこで数学者の叡智により編み出されたのが
#パズルができた訳 今シンガポールのスタートアップでエンジニアをしているのだが、半年ほど前にソフトウェアエンジニア向けの求人募集ページに簡単なプログラミング系のパズルを出して、それが解けた人だけ応募できる仕組みにしよう、という話になった。 その時期は求人を拡大募集していたのだが、あまりにハズレな人が多かった。私もいくつか面談をしたのだが「CV(履歴書)には高いスキルって書いてるけど、言ってることがなんでこんなに変なの?」と感じてしまう応募者が多かった。これは私だけの意見でなく、他のエンジニア達からも不満が続出した。つまり履歴書のスクリーニングが効いてないということだ。日本よりも海外の方が履歴書を誇張する率が高い気がする。そこで考えたのが求人募集ページにエンジニア向けのパズルを出す、という発想。 #パズルのコンセプト 言ってはみたもののどんなパズルにしようかと考えると案外難しい。 パズルの条
このページを最初にブックマークしてみませんか?
『@jabbaのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く