個人開発のWebサービスで、Trelloを使っていい感じに開発ロードマップを公開した話Sep 29, 2017 個人開発論Trello 個人で開発しているトーナメント表作成サービス「THE TOURNAMENT」で、今後の開発予定などを載せた開発ロードマップをTrelloで公開しました。 前から開発ロードマップは作りたかったのですが、なかなか作り方・運用をどうしたものか悩んでました。 今回Trelloを使ってみたらなかなかいい感じにできたので、やった内容をメモしてみます。 なんで開発ロードマップがほしかったかこれはいくつかあります。 サービスがちゃんと運営されてることを伝えたいまずはこれですね。 開発ロードマップがあると、死んだサービスじゃなくて、 ちゃんといまも積極的に機能追加されている生きたサービスですよってことが伝わるかなと。 Webサービスを探して使うときって、ちゃんと運営が安定し

この記事は「Visual Studio Code Advent Calendar 2017」の7日目の記事です。 昨日は@74thさんの「Visual Studio Codeの各言語、環境のデバッグの仕方を集めたサイトを作ってる」でした。 明日は@Maxfield_Walkerさんです。 私からは「Visual Studio CodeでJavaを書いてみた話」をしたいと思います。 なんでVisual Studio CodeでJava書くの？ Javaのコードを書くとき、通常であればIntelliJ IDEAやEclipse、NetBeansなどのIDE（統合開発環境）を使います。コード補完やJavaDoc、ビルド、ユニットテストなど、様々な機能と周辺ツールを利用可能で、効率良く開発ができるためです。 私はJava EE開発をやっていたので、ずっとNetBeansをメインに使ってきたのですが

[React Native入門完全版]「いきなりデート」のアプリをReact Nativeで開発した知見をまとめます。 この記事で説明する事 React Native採用に係る意思決定の話 atom + eslint + flowによるIDE風開発環境 line by lineによるプロジェクト作成方法とリリース方法 デバッグ方法やtips集、補助ツールの使い方 React Nativeとは Facebookがオープソースとして開発するReact.jsの思想の一つである「Learn once, Write everywhere」（元ネタはもちろんJavaのWrite once, Run anywhere）を体現した、Facebookが開発主体となるプロジェクトの一つで、要はJavascriptとReactフレームワーク1つでモバイルアプリ（iosとAndroid）を作れる、といった代物です

「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/users/1/neganin/web/neganin/wp/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 77 Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/users/1/neganin/web/neganin/wp/wp-content/plugins/jetpack/_inc/lib/class.media-summary

なんかいい映画ないかなぁと思うことは誰にだってありますよね。ちょっと時間ができた時なんかに、映画でも見てみようかと。でもこれはそんなに簡単なことではありません。 世の中にある映画なんて多すぎて一体いくつあるのか分からないくらいですし、一回選んだらだいたい2時間は取られるわけです。おもしろくない映画に2時間奪われるリスク、そして最高の映画を見ずに人生を終えてしまうリスク。こんなハイリスクを背負って僕たちは映画と向き合っていかなければいけません。 恐ろしい。 こんな恐ろしいことがありますか。 でも安心してください。機械学習がそれを解決してくれます。今回の記事では、機械学習を使って、自分自身に映画をおすすめするモデルを作ってみました。 何は無くともまずはデータが必要です。今回はみんなのレビューサイトさんからデータを拝借しています。 みんなのレビューサイトでは、レビュアーが自身のプロフィールを登録

本シリーズでは、「FXの予想プログラム」を作りながら、機械学習・ディープラーニングを解説します。 （注）のび太くんは有名漫画のキャラとは一切関係ありません。 あらすじ 「のび太と機械学習」は、20歳の大学生、のび太くんが主人公です。 大学生のび太くんは、お小遣い欲しさにFXに興味を持ちます。 そんなのび太くんに、家庭教師のすぐるさんが、機械学習を解説し、FX予測プログラムを一緒に作ります。 残念なことに、FX予測プログラムは、ちょっとしか儲かりませんでした。 ・ ・ ・ のび太くんはその後、学んだ機械学習を生かして、D-mind社を起業し、汎用人工知能を作り上げます。 高齢になったのび太くんは、D-mind社をTMR社に売却し、TMR社の工場で22世紀、汎用人工知能搭載型ロボットが誕生します。 この物語は、そんな汎用人工知能搭載型ロボット誕生につながる、のび太くんの機械学習・勉強記録です。

こんにちは、たくやです。最近すっかりニュース担当として定着してしまいましたね。 今回はgoogle が公開した教育と研究のための研究ツールである Colaboratory について解説していきたいと思います。 ざっと検索してみたところ英語版でしかまだ記事が出ていないようでしたので、日本語版最速と題させていただきました。 ニュース概要 ColaboratoryはJupyter notebookを基盤としたオープンソースプロジェクト。現在、ColaboratoryはChromeのデスクトップ版でのみ動作する。優れたユーザーエクスペリエンスを提供するために、当初はノートブックの作成や編集へのアクセスを制限して　　　　　　いる。そのため、利用するには申し込みをしなくてはいけない。ColaboratoryノートブックはすべてGoogleドライブに保存される。既存のJupyter / IPythonノ

ここでは、フロントエンド開発の概要について説明していきます。 ＊元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。

はじめに Webフロントエンドの知識がjQueryで知識が止まっていたので、モダンなWebフロントエンドに触れてみた。そのメモ。 良かった点 「今はこうなっているのかー」と分かった。今後はナウい記事を読んでもビビらないと思う。 Reactのすごさ 触ってみて下の記事のいうことが理解できた。何がすごいの？と聞かれたら下の記事を掻い摘んで説明したい。 Reactを使うとなぜjQueryが要らなくなるのか 触ってみたもの ES6 Yarn Webpack Babel Sass/SCSS React とりあえずエディタ開いてHTMLを書くぞというタイプの人間だったので、フロントエンド開発にまずはコマンドラインを打って環境を構築する点が新鮮。自動化できるところはツールで共通化してラクできるところはラクをする、というのは分かった。Reactは使うか分からないが、Webpack/Babel/SCSSは絶

こんにちは。みなさんもウェブアプリをリリースしたあとに同業者にソースごとパクられたことってありますよね。難読化しても難読化されたまま同業者のサーバで動くので困ったものです。そこで、私がとった解析しずらい対策をまとめてみたいと思います。 前提 多機能な画面をJavaScriptでゴリゴリ作ったのにもかかわらず、HTMLやCSS、JavaScriptファイル一式を自社サーバにまるごとコピーして、ライセンス表記だけ書き換えて使うような業者を罠にはめるということを想定しています。 当然通信をリバースエンジニアリングする人もいるので、自社サーバでは防げないという前提です。 HTMLにはauthorメタタグ よくあるMETAタグで権利者を明記します。これは権利の主張もそうですが、JavaScript自体に権利者が認定した権利者でなければ無限ループを起こすという処理のためにも使用します。逆に、権利者が我

さて、改めて今回の目的を確認しておくと、機械学習を使って東京都23区のお買い得賃貸物件を発見しよう、というものです。前回までの記事で、お買い得賃貸物件を発見するためのデータを収集し、分析にかけられるよう前処理してきました。 www.analyze-world.com www.analyze-world.com 今回の記事では、いよいよ機械学習を使って分析していきましょう。前回まではPythonを使っていましたが、この分析ではRを用いています。なお、コードはGitHub（https://github.com/ShoKosaka/Suumo）に上げておきますので興味ある方は参照ください。 最初に、データの中身をざっくり見ていきます。具体的には、分析のキーになるポイントをグラフにしながら、賃貸物件の現状や変数同士の関係性を把握していきます。 データ探索 まず、23区の中でどこが物件数が多いのかを

Web サイトを開発する際のアーキテクチャ設計において、ユーザーの認証にはメールとパスワードを利用するのが一般的でしょう。この設計は身に染み付いていて、なぜユーザーにパスワードを作成させるのか、考えもしないかもしれません。私たちは慣れてしまったのです。 しかし、ユーザーはパスワードを必要としない可能性があります。 一つの解決策は OAuth 2.0 ですが、すべてのユーザーがSNSのアカウントを持っているわけでもなく、あなたのサイトでそのアカウントを使用したいと考えているとも限りません。 では、あなたはどのようにしてパスワードを使わずユーザーを認証しますか？その回答はこの記事を読めばわかります。 何が問題か？ 最も安全なパスワードは、あなたが覚えられないパスワードです Troy Hunt そもそもパスワードそれ自体に問題があります。あなたや、あなたのユーザーにとっても良いものではありません

NewRelic / Elasticsearch ではじめるSREに必要な性能監視入門 https://supporterzcolab.com/event/177/ にて話した資料です！

どうもせせりです:) 19歳の頃からほぼ1人でRailsでWebサービスを作り始めて早7年 紆余曲折ありなんだかんだで作ったサービスは30個ほどになりました 7年ほど前に一番最初に作ったTwitterアカウントで「僕の夢は25歳までに3億円を稼いで残りの人生を楽しむ事です」などと言っていました あれから7年がたち26歳になり、3億円は無理でしたが残りの人生贅沢しなければ働かずに生きていけるくらいにはなりました Rails勉強会、ハッカソン、未踏、などなど色々参加していましたし、狭いRails界隈なのでもしかしたら勉強会などでお会いした方は覚えている方もいるかもしれません 色々お話を聞いてくださりアドバイス下さった先輩方ありがとうございます あの頃の初心者は無事に夢にたどり着きました！ 振り返ってみれば訴訟起こすぞって怒られたり、警察から電話がきたり、サーバー会社にサービス止められたり、サー

CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい！と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ

「ついカッとなって……」取り組んだ 開発者のための開発 で業務効率を改善させた話 ソフトウェアエンジニアの醍醐味は、華々しい働き方のみにあるものではありません。開発者のための開発など、地味かもしれないけど楽しくやりがいのある仕事について紹介します。 アプリケーションエンジニアの id:aereal です。はてなで働いています。 昨今は機械学習などが半ばバズワードと化し、「トレンドを追いかけなければソフトウェアエンジニアとして生き残れないのではないか」という漠然とした不安に襲われることはないでしょうか。 これという専門分野の技術を活かし、所属する企業やひいては社会へ貢献するというあり方は、技術職として華があり憧れを誘うものです。 しかしソフトウェアエンジニアの醍醐味はそういった華々しい働き方のみにあるものではなく、むしろその他の様々な分野にたくさん散りばめられていると筆者は考えます。 この記

ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ