【個人開発】爆速な賃貸物件の検索サービスを作った - Qiita
個人開発で 賃貸物件の検索サービス Comfy を作りました1。グラフや地図でサクサク絞り込める UI が特徴のサービスです。とにかく気持ち良い使い勝手を実現するために色々工夫しています。 既にリリースからは 4 ヶ月以上経っているのですが、改めてサービスの概要や、システム構成及び使用した技術・サービスをご紹介しようと思います。2。 サービスの概要 Comfy は日本全国の賃貸物件を検索できる Web サービス です。画面 UI は上の GIF 画像のような感じです。 こだわったポイントを色々書くよりも実際にさわって頂いた方が新感覚の UI や気持ちよさを体感頂けるかと思いますので、 実際のサービス をぜひお試し頂ければ幸いです！ システム構成 図の通り、システムは大きく 3 つに分けられます。 フロントエンド バックエンド データ基盤 使用技術は図の通りではあるのですが、フロントエンドと
完全未経験が半年で個人サービスをリリースした話 - Qiita
はじめに この度、転職とスキル向上を目的に個人サービス(Football League)をリリースしました。 ITに関する学習は約1年ほど、その内の半年でサービスの開発をしました！ まだまだ修正箇所はあるものの、ひとまず形にはなったのでサービスの使用技術や開発過程を共有したいと思います。 私自身、独学で学習してきたのでそういった方々にとって少しでも参考になれば幸いです。 自己紹介 商業高校卒(サッカー部⚽️) 25歳 青森住み🍏 職業はトマト農家です🍅 どのようなサービスか 本サービスは、欧州5大リーグのサッカーの試合結果やチーム情報などを閲覧することができるWebサイトです。 ただ情報を閲覧できるだけでは面白みがないので、お気に入りのチームやリーグを追加することもできます。 なぜ作ろうと思ったか 私自身、小学生の頃から社会人になった現在までサッカーをやっています。 サッカーだけではな
自作した時間割アプリが大学の公式アプリに採用された話 - Qiita
記事の概要 私（芝浦工業大学学部4年生）が大学3年時に1人で制作した、大学のポータルアプリ（ポータルサイトからスクレイピングして時間割などを表示する）が、大学に正式採用され、公式アプリ"ScombApp"としてリリースされるに至った経緯を時系列順に説明します。 ホーム画面 時間割画面 制作の動機 大学のポータルサイト使いにくいがち。 ポータルサイトのスマホアプリ版があれば便利そう。 他にやってる人いなさそうだし、最初に作ったらみんな使ってくれそう。 ポータルサイトの問題点 大学ポータルサイトで使いにくかった点を挙げていく。 とりあえずこれを克服することを目標にした。 ログインの時に自動補完が使えない 制作当時はBASIC認証で、スマホからだとログインの自動補完ができなかった。 毎回手打ちでパスワードを入力している人がほとんど ←！？ 次の授業や教室を確認するだけでも、毎回手打ちログインが必
個人開発のコストはDB次第 - laiso
個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある 「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。 そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。 通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。 ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。 仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいか
ProtoPedia | つくる、たのしむ、ひろがる
あなたのライフワーク作品を投稿。 まとめると開発がもっと楽しくなる。 いつも作ってるあの作品。 アイデアの発想、苦労したポイント、 こだわりの機能など、あなたの思いを残しませんか？
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
シニアフロントエンド開発者みたいにChromeデベロッパーツールを使おう - Qiita
開発環境にChromeを選ぶなら知っておきたい12のテクニック Photo by Morning Brew on Unsplash さて、何らかの理由で、開発ブラウザとしてChromeを選んだとします。次は、デベロッパーツールを開き、コードのデバッグを開始します。 Consoleパネルを開いてプログラムの出力を確認したり、Elementsパネルを開いてDOM要素のCSSコードを確認したりします。 でも、Chromeデベロッパーツールを本当に理解していますか？実は、パワフルだけど知られていない機能がたくさん用意されていて、開発効率を大幅に改善できるのです。 ここでは、最も便利な機能を紹介します。お役に立てたら嬉しいです。 ChromeのCommandメニューから始めましょう。ChromeのCommandメニューは、LinuxのShellのようなものです。コマンドを入力してChromeを操作で
RuboCopコミッターが語る、"Write Code Every Day"を5年間実践するための工夫と得られたもの | Offers Magazine
エンジニア界隈では「GitHubに草を生やす」という言葉があります。GitHubに草を生やすとはどういうことか？また草を生やし続けるコツ、草を生やし続けた先の世界観を自身のOSS開発のキャリアをふりかえりつつ紹介します。 私と”Write Code Every Day"との出会いは、とちぎテストの会議03の休憩時間でのこと。毎日コードを書くことを実践している話をt-wadaさんから聞いたのがきっかけだったと思います。 すごい人の真似をすればすごい人に近づけるだろう、という単純な発想から始めましたが、"Write Code Every Day"のオリジナルのルールは「真夜中にコードを書かない」など、私には厳しいものでした。 そのため、教科書的に進めようとしてスタートで挫折するより良かろうと、自分でできそうな形にカスタマイズで実践してきています。ルールは単純でGitHubに毎日草を生やすという
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
求む、同志 - 川口耕介のブログ
既報のように、こないだから、ここ十年来のプロジェクトであるJenkinsを離れて、新しい事業Launchableを起こしています。ソフトウェア開発者の生産性を上げたい、もっとデータと機械学習を使って、開発者の外骨格である自動化されたプロセス達が効率よく、頭良く実行されるようにしたい、そういう思いを持って取り組んでいます。おかげで、お金もちゃんと集まったし、全米各地の優秀な人達を集めたチームを作ることが出来たし、お客さんも開拓されつつあるし、t_wadaさんにも「強いシンパシーを感じる」とまで言ってもらって、心を強くしています。 デブサミ登壇後は控室で @kohsukekawa さんとずっと議論していた。川口さんの新しいプロダクトに役立つかもしれないアイデアをいろいろと話せてとても充実した時間だった。技術カンファレンスは廊下や控室での対話にも大きな価値がある。 #devsumi — Taku
個人開発で100ヵ国以上が参加するトーナメントで世界1位を獲るまで - Qiita
はじめに Pioneerで1位を獲りました。このトーナメントは、世界100ヵ国以上から個人開発者/起業家が参加するアクセラレータープログラムとなっており、誰でも参加することができます。参加すると、週次で「その週どんなことをしたのか」、「どんなKPIを設定しているか」を提出し、他の参加者やメンター陣の評価によりポイントが付与され、順位が変動する仕組みが設けられています。 したがって、数日で終わるイベントではなく、1ヶ月〜半年以上かけて行なわれます。また、上位ランクに入ると、Pioneerからトップランカープログラムの招待があり、GoogleやAmazonなど合計200K相当のクレジット、限定コミュニティへの参加や、著名起業家からのメンタリングを受けることもできるようになります。Pioneerの主催者が、シリアルアントレプレナーかつ、元Y CombinatorのパートナーでもあるDaniel
質とスピード（2020春版） / Quality and Speed 2020 Spring Edition
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
Developers Summit 2020 で登壇してきた | DevelopersIO
はじめに こんにちは、グローバルチーム担当兼アジャイルコーチの藤村です。2020年2月13日〜14日にホテル雅叙園東京で開催されたDevelopers Summit 2020で、「アジャイル開発の原則を守りつつ、マルチサイト開発を行なう！ ～ベトナムのメンバーとともにつくる～」という発表をしてきました。 登壇資料 私の発表資料はこちらです。 経緯 今回はデブサミコンテンツ委員会の黒田さんからご推薦頂き、登壇させて頂くことができました。 今回のテーマは「ともにつくる」なのですが、「グローバルチームでともにつくる」といったテーマで、お話いただけないでしょうか。 このような選考理由をお聞きし、まさに今ベトナムとのグローバルチーム作りを進めている自分としてはぜひお話したいテーマだったので、快諾した次第です。 思えば2015年のデブサミの公募に応募して落選して以来、デブサミでの登壇は諦めちゃってたの
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、
消えたプログラマの残したものは - megamouthの葬列
システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の本人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい
レガシー開発環境を今風の開発に近づけるために一年やってきたこと - Qiita
自己紹介 @pugiemonn といいます。 オンラインサロンプラットフォームを手掛けるシナプス株式会社で開発とマーケティングを担当しています。 今日の話 1年前にレガシー環境に参加したメンバーがレガシーな問題に対して、どのような取り組みを行ってきたかお話します。 開発チームメンバーゼロ問題 社長１人で3年開発していた １人で走るのはつらい 突然ユーザー数が増加しはじめピンチに 求人がんばった結果 チームメンバー10名（インターン生含む）になりました✨ バージョン管理されてない問題 1人だったのでバージョン管理など無かった GitとGithubを導入した結果 まずはSourceTreeから 作業ログがわかるようになった 問題発生箇所の調査が容易に 作業がチケット化されていない問題 1人だったのでチケットなど無かった 何のタスクかわからない チケット管理した結果 何の作業かわかるようになった
チーム開発を始める時に決めること - GeekFactory
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略
HTTP/1.1 200 OK - Qiita
※このお話はたぶんフィクションです。実在の人物や団体とはあんまり関係ありません。 序 planetter.comをバージョンアップすることにした。数年前にリリースしてからずっと放置していたけど、そろそろ手を付けないとやばいと思った。 しかしウェブの世界はドッグイヤーだ。3年も経てば何もかもが変わっている。しばらく開発から遠ざかっていた僕には、最近の技術トレンドなんてさっぱりわからない。 まずは自分自身をアップデートするところから始めよう。 Atom 最初はIDEだ。以前はEclipseを使っていたけど、いまはもうウェブ系言語の進化速度に追いつけていないようだった。ウェブ開発用のIDEならいまはWebStormが人気のようだ。有料だけど、最新の技術に対応しているし、使い勝手もいい。 でも最終的にはAtomを選んだ。IDE(統合開発環境)ではなくエディタなので、これ自体は単機能だけど、不足分は
イベント資料｜dots. Summit 2015 - ドッツサミット - - TECH PLAY［テックプレイ］
今回はサンドウィッチなどの軽食をご用意しました。予想以上の反響で全員の手に行き渡らなかったとの悲報がチラっと、、、（申し訳ありません）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いコードとは
