現在、AWS環境を新しく使用する会社のインフラ周りの面倒をみているのだけれども。 その会社はとあるAWSを専業としているシステムインテグレーターにAWSの構築を発注したらしい。 経緯は不明だけれども、出来上がったものは以下のようなものでした。 AWS上にインターネット上に公開するサーバーを置く そのサーバーへの社内からのアクセスのためにDirect Connectを使用する AWS上に配置されたサーバーからは社内ネットワークへ無制限のアクセスができる Direct Connectっていわゆる専用線接続で、お客さんのネットワークとAWS上を一体化させていろいろな通信をインターネットを使わなくても行えるようにするものだけど、そういったリスクを何も伝えずにDirect Connectを提案したうえで、セキュリティ設定を何もせずに、インターネットに公開するサーバーから社内への無制限アクセスをできる

この件について改善がなされるとの発表がMicrosoft DOCS International Teamからありました。 少なくとも、誤訳の報告についてはやりやすくなるそうです。 ご担当者様及びに尽力してくださった方々には感謝いたします。 https://github.com/dotnet/docs.ja-jp/issues/118#issuecomment-408283458 今回の私の記事に憤ってる人たちは改善されたことを確認するためにドキュメントフィードバックを送りまくってそれをブログにでもまとめればいいと思うんですよ。— 軒先のネコ (@megascus) 2018年7月28日 -----------------------------------追記ここまで---------------------------------------------- ということで、おとといぐらいか

もらったわけではないですが、買ったので。 Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門 (Software Design plus) 作者: 前橋和弥出版社/メーカー: 技術評論社発売日: 2016/06/07メディア: 大型本この商品を含むブログ (1件) を見る これはServlet APIを動かす側、つまり、Servletコンテナを実装してみようという本です。 JavaでWebアプリケーションを実装していると、TomcatやGlassFish等、すでにあるリッチなAPIを使用した開発のみを行いますが、 HTTPをラップしているだけなので、HTTPを知らないとよく判らない不具合にあたることがあります。 java.lang.IllegalStateException: レスポンスをコミットした後でセッションを作成できません というメッセージとかよく見たことがある

工夫しようは使う必要がない。工夫したなら、使ってもいいッ！ ※このエントリはどこかの組織を代表して言うものではありません。個人的な意見なのでご注意ください。 忙しい人のために3行で。 東京ではドタキャンが3割ぐらいいる。リマインダすることでドタキャン率は明確に変化する。 ドタキャンしなければいけない側にもそれなりの理由があると思うのでdisるのはやめよう。 有償の勉強会はどんな理由があろうとも勉強会という形式ではやらない方がよいです。 日本Javaユーザーグループで活動をはじめて2年がたちました 日本Javaユーザーグループ(以下JJUG)の幹事をやっています。月一回ナイトセミナーという形で勉強会を運営しています。 なんだかんだで勉強会運営の元締めみたいな感じになっていてノウハウがたまってるので共有します。 通常の勉強会について 勉強会は大体無償の形でやってます。たいていOracleさんの

この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必

IT業界で働いていて色々な職場の話を聞いていると労務について知らないことが多すぎるなーと思う。 例えば、 振替休日と代休の違い 残業代は年棒制でも払わなければいけない 深夜労働は深夜手当が必要になる 自宅待機は厳密には勤務時間に含まれる とか。 http://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/roudoukijun/index.html 弁護士の方とか社労士の方とか率先して勉強会とか開いて顧客集めすればいいんじゃないかなー。 2014/1/22追記 twitterで[twitter:@yamadamn]さんからいただきましたが、自宅待機は勤務時間には含まれないという判例があるそうです。 どこに居るかも重要であるらしい。 http://www.rosei.jp/jinjour/article.php?entry_no=

あまり技術力もない、口も下手で、日々のシステム開発を大きな不具合がないように先回りをしながら大きな苦難の無いように仕事をしているプログラマーよりのエンジニアによる感想です。 何回か転職をしてきて、エンジニアの採用面接は非常に不思議だと思うようになってきました。 その思いを完成させてくれたのはJunichiItoさんによる このたびソニックガーデンの7人目のメンバーになりました でした。 自分が不思議と思ったことを5つほど挙げたいと思います。 システム開発の判らない人が評価をするのですか？ 最初に不思議に思ったのは面接を人事の方がすることが多いことでした。 システム開発をしたことがない、することのない人が面接官をして、 エンジニアが自分がどれだけ優れているのかを面接でお話をする。 エンジニア同士ですら、昨今の技術は多岐にわたっており、自分の専門としていない分野に関しては評価ができないような状

これはTDD Advent Calendarの18日目。 記事としては @mao_instantlife さんの TDDやってみてコメントが減った話 のあと、@cubeon さんの きっと方眼の理から逃れられないお前たちにも告げる！テストコードを手に入れるのだ！ の前となります。 最近、新しい開発手法の一貫としてTDDを採用しようとするプロジェクトが出始めている印象があります。 ただし、とりあえず取り入れてみたけれどもうまくいかなくて結局ウォーターフォール方式に逆戻りという例も多いのではないでしょうか。 以前、アジャイルにTDDをしようとしてペアプロして失敗したプロジェクトの話を聞いたことがあるので書こうと思います。 その時のプロジェクトでは数百人月前後の工数をかけてそれまであったレガシーシステムをJavaでリプレイスしようとしていたようです。 それなりの規模のプロジェクトに多いように、さ