以前から熊本でJavaの勉強会に参加していたが、今回はSpring Bootのハンズオンをしてくださった。どちらかと言うと自分がAngularをやっていて、そのRESTなサーバをJavaで作りたいが最近のJavaはよくわからんということでやって頂いた、感謝。 kumamotojava.doorkeeper.jp やったこと githubに書かれているチュートリアルを解説付きでコーディングした。IDEはNetBeensで、テキストはこちら: github.com mavenのインストールからプロジェクトの作成 Thymeleafの追加 JPAの追加 htmlでの表示 RESTでのAPIアクセス JDBCでのDBアクセス デプロイ実行 全体的にSpring Bootの初心者ハンズオンはできた 感想 やっぱり最近のJava(というかSpring)はアノテーションベースだなと。最近と書いたがだいぶ
ちょっとバージョンアップ http://qiita.com/koh110/items/f6ecbdc03093675a9527 自分なりに使いやすいフロントエンドの開発環境を整えて使っていたけれど、だんだん時代の流れにそぐわない箇所が出てきたのでその部分を書き換えてアップデートしてみた。 http://qiita.com/koh110/items/9c750fb67e40481e52cd 昔のバージョンはv1.0.0というブランチに切り出し https://github.com/koh110/minjsapp やめたもの gulp-load-plugins run-sequence bower モジュールやライブラリへの依存度を下げたかった 変更したもの gulp-babel -> webpack + babel-loader requireしたかった 追加したもの sassコンパル 生c
少し前の記事(「プログラミング未経験者がWEBエンジニアになるためにやるべきこと」)の元になったプログラミング初心者の二人が、それぞれ無事Railsのチュートリアルまで終わらせていざ自分のサービスを作りたい!ってなった時に、さて何から手をつけたらいいんやろう?という同じ悩みにぶつかって同じようなアドバイスをしてたので、またその内容をまとめてみました。 初心者に限らず、小規模WEBアプリを作る時にこういうことをしとくといいかなっていう個人的な手法みたいなのをざっくり書いていきます。 SPONSERD LINK 前提 一般的なシステム開発は下記のフローで進んでいきます。 要件定義 設計 開発 テスト リリース ウォーターフォールはこれを1回流して完成、アジャイルはこれを小さく切ってぐるぐる回すというイメージですが、「初めての個人アプリを最初にリリースするまで」という状況では、一番困るのは2の設
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう!『だるさ』見積り!本当に大事だよ! [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
はじめに Webパフォーマンスはパフォーマンスエンジニアリングの1つの分野 Webパフォーマンス管理は、Webサイトの非機能要求の性能や可用性を扱います。 専門用語では、コンピュータの登場と時期を同じくして登場したパフォーマンスエンジニアリングという分野に属します。 パフォーマンスエンジニアリング パフォーマンスエンジニアリングとは、Wikipediaでは以下のように記載されています。 Performance engineering encompasses the techniques applied during a systems development life cycle to ensure the non-functional requirements for performance (such as throughput, latency, or memory usage) w
先日公開した「UIテストの自動化!Node.jsとSeleniumでWebアプリのUIテスト環境構築」では、手動で行っていたWebアプリのUIテストをSeleniumを使って自動化する手法についてご説明しました。 SeleniumでUIテストを自動化することにより、リグレッションテスト(改修により既存機能への影響がないかを確認する回帰テスト)が簡単にでき、バグの早期発見に繋げることができますが、実際にはこのテストを運用でしっかりと行っていかないとプロジェクトとしての品質向上にはつながりません。また、コマンドラインの扱いに慣れていない方は、コマンドラインからのテストの実行に抵抗があり、テスト結果もコンソールに出力されるため見づらいと思う方も多いと思います。 そこで今回はCI(継続的インテグレーション)ツールであるJenkinsとSeleniumを連携することで、定期的にテストを実行し、テスト
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
はじめに 「Charles」はHTTPのプロキシ・モニタを行えるGUIのツールです。似たようなツールとしてはFidllerが代表的ですが、CharlesはUIや操作性がシンプルです(その分機能は限定的です)。「HTTPをモニタする」というとなんだか取っ付きにくそうに感じるかもしれませんが、Charlesを使うことでその認識は大きく変わります。今回はこのツールのさまざまな使い方をWebフロントエンドの開発視点から紹介していきたいと思います。その便利さから弊社のWebフロントエンド開発チームにはなくてはならないツールとなっています。 Charlesとは Charlesは公式サイトの説明にもある通り、HTTPプロキシ/HTTPモニタを行うツールです。機能を大きく分類するとできることはその2点だけですが、かゆいところに手が届く細かな機能を多く持っています。公式サイトから引用すると、機能としては以下
このページの目的は、 Webアプリケーションの基礎の基礎を説明することです。 さて、ここから下のぐだぐだは読み飛ばして、 いきなり実装の説明に 行ってもらってもかまいませんが、一応趣旨を書いておきます。 現在、プロのプログラマーの方々には、日々の仕事でせっせと 「Webアプリケーション」を作っている人が多いと思います。 そして、いまどきWebアプリケーションを作るのに、 CGIとかあり得ないでしょうから、 それなりの高級言語で、 それなりのフレームワーク等を使用して作っているのだと思います。 私自身、現状、仕事では主にC#とASP.NETを使っています。 そうやって生産性を上げるのは大変よいことだと思うのですが、 ことWebアプリケーションにおいては、 そのような「一見簡単そう」なフレームワークを使っても、 ちょっとややこしいことをやろうとするとすぐにうまくいかなくなって、 職場の先輩に聞
The document summarizes quotes from three individuals about web design and development. Tim Berners-Lee notes that the primary principle of the web is universality, meaning it should be accessible from any device. Jason Fried argues that designing in Photoshop wastes time, as the design then needs to be rebuilt in HTML/CSS. Instead, one should design directly in HTML/CSS to allow for faster iterat
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
はじめに これはソフトウェアテストあどべんとかれんだー 2014 の14日目の記事です。 明日は id:kokotatata さんです。 概要 パフォーマンステストを入門するための情報を紹介します。発端は@ryushi さんが次の記事でなにやら不思議な言及をされていたというところです。 正直に申し上げて負荷テストって恐ろしく難しい種類のテストなんですけども、特にその難しさについては書いていませんので、きっと名古屋辺りのうさぎさんが補足資料を提示してくれるでしょう。よろしくお願いします。 注意 ここにあるのはkyon_mmの私見です。なので、「なに、こいつ大げさだな。。。」とか思ったらコメントで「それはお前が勉強不足だからで、世のエンジニアの感覚と違います」とか書いてください。温度感重要です。 参考書籍 基本的にはこれらを読めばいいのかなと思っています。この記事で書くのはこれらで言っているこ
python × 120 javascript × 50 c# × 34 python3 × 31 html × 31 c++ × 28 linux × 27 c × 26 java × 21 windows × 20 android × 16 ruby × 16 google-apps-script × 16 php × 15 css × 15 reactjs × 15 typescript × 15 docker × 13 aws × 12 pandas × 12 swift × 11 ruby-on-rails × 11 mysql × 11 unity3d × 11 node.js × 11 ubuntu × 11 vscode × 11 postgresql × 11 rust × 10 macos × 9 visual-studio × 9 laravel × 9 networ
11/15 スタートアップ・リーダーシップ・プログラムにて、事業起業を考えている皆さんに向けてお話した内容を加筆修正して公開しました。 http://startupleadership.jp/Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く