米国の軍艦がエイリアンとの戦闘で沈没する場面などが、静岡県・伊豆半島沖で起きた米海軍イージス駆逐艦の衝突事故を連想させるためという。
ImPACTタフ・ロボティクス・チャレンジは、災害の予防・緊急対応・復旧、人命救助、人道貢献のためのロボットに必要不可欠な、「タフで、へこたれない」さまざまな技術を創りだし、防災における社会的イノベーションとともに、新事業創出による産業的イノベーションを興すことを目的とし、プロジェクト研究開発を推進しています。 災害危険地域では、遠隔・自律で重作業を行うことが必要ですが、これまでの遠隔建設機械は、器用さが不足、重作業が不可能、斜面や段差での移動に限界がある、遠隔操作が困難で作業効率が低い、という問題があり、根本的な解決が望まれています。本研究開発は、2重旋回・複腕機構と高出力油圧ハンドにより、これらの問題の解決を図ろうとするものです。重量物のハンドリングが可能な複腕により、作業や移動の能力を飛躍的に向上させ、高出力ハンドにより様々な掘削や把持を可能にする、非連続イノベーションを目指していま
はじめに アクセス数が多くない場合は、AzureのWeb Appは「F1プラン」を利用することで、無料運用が可能な様子、という話。 Azureの無料試用期間が終了に伴い無料プランへ移行してみたので、その手順を示す。 以前に書いた「Node.jsで作成したWebサービスをAzureで公開する」を 「無料試用プラン」⇒「F1プラン(無料)」へ移行してみた。 作業方針とプラン移行作業前の状態 基本的には、下記の記事を参照して作業した。 Azureの無料試用期間終了後に無料オプションを使う Part-1 - Qiita Azureの無料試用期間終了後に無料オプションを使う Part-2 - Qiita 異なる点は、当方は無料試用期間が切れる前ににアップグレードした、部分だろうか。 期間が切れる6日ほど前に「billing@microsoft.com」さんから、「無料試用版 サブスクリプションの無効
Azure 無料アカウントとは何ですか? Azure の無料アカウントを作成することは、Azure のサービスにアクセスするための 1 つの方法です。無料アカウントで Azure の使用を開始すると、サインアップしてから最初の 30 日間、 USD$2001 のクレジットを利用できます。さらに、12 か月間無料の人気のあるサービスと、常時無料の 55 以上のサービスという、2 つのサービス グループを毎月無料で利用できます。
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に3年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
オブジェクト指向にもとづくクラス構造を、本来異質なRDBのテーブル構造に対応させることをOR(Object-Relational)マッピングといい、そのための仕掛けがORマッパーである。代表的なものがHibernateやJPAで、これらを使うことは、WEBアプリ界隈では常識といっていいものになっている。しかし、これを業務システム開発で利用するのは、特別な事情がない限りお勧めできない。 ORマッピングの技術は良いものと悪いものとをもたらした。良いものとしては、Ruby on Railsのような生産性の高い開発環境を挙げられる。じっさいRailsは、TwitterやGithubといった優れたサービスの基礎として社会に貢献した。いっぽう、業務システム開発の世界に対しては、ORマッパーはどちらかといえばハタ迷惑な影響ばかりをもたらしたと言わざるを得ない。テーブル構成が比較的単純に済むWEBアプリを
DB(データベース)設計の良し悪しは、開発プロジェクトのパフォーマンスに決定的な影響を与える。ところが、ショボいDB設計のまま突っ走るためにその場をしのぐ方法が山ほどある。50はある。ポール・サイモンの歌みたいだ。 私は駆け出しの頃、いろいろなプロジェクトの設計書を覗きまわるのが好きだった。「プログラム仕様書」は情報量が多すぎて手に余ったが、「テーブル定義書」からは短時間で多くのことを学べた。 読み漁るうちに、設計者の馬脚がDB設計に現れることがわかってきた。DB設計はある意味で、担当者の論理構成力や言語能力の結実である。DB設計書を半時間ほど眺めれば、そのプロジェクトが「うまくゆくかどうか」まではわからないにせよ「困ったことになるかどうか」は予測できた。とくに、DB設計からシステム要件を把握しにくいプロジェクトは、規模が大きければ決まってデスマーチに突入していった。 私はコトナカレ主義の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く