2022/1/13をもって お客様がご利用中のブラウザ (Internet Explorer) のサポートを終了いたしました。 (詳細はこちら) クックパッドが推奨する環境ではないため、正しく表示されないことがあります。 Microsoft Edge や Google Chrome をご利用ください。 (Microsoft Edgeでクックパッドにログインできない場合はこちら)
>最も速い宇宙船の航海速度はヘリオスの252,800 km/hだと聞きました。 宇宙に行ってから推進機やスイングバイで加速することが行われますが, そもそも打上ロケットでめちゃめちゃ加速する方法もあります. その場合,打上ロケットにはブースターをいっぱいつけます. いま冥王星に向けて飛んでいる「ニューホライズンズ」も力業で, 地上から16.2km/sの最速で打ち上げられ,9時間で月を通過,78日で火星を通過,13ヶ月で木星に到達,現在も飛行中です. >ロケットエンジン以外の夢のような推力装置があれば教えてください。 今のところ人類は,次の2種類の推進装置しか知りません. 1.物体を放出又は受け止めて,その反作用で推力を得る. 2.場(地磁場など)との干渉を利用して推力を得る. 目下,夢の推進機関としては,「核融合推進」ですね. これは「比推力」が何万秒と言うものです. (通常のロケットは数
2014年6月30日 10時49分 by ライブドアニュース編集部 ざっくり言うと 地球とほぼ同じ大気と気温をもつ星「Gliese 832c」が新たに発見された 地球から16.1光年離れており、天文学的には非常に近い距離にある 研究者は「生命体が存在する可能性が高い」と述べている 広いには地球に似たような大きさ・質量を持つ星が無数にあり、中には太陽のような恒星の周りを回る惑星で生命体が存在する星もあると考えられています。そんな中、地球に極めて似た星「Gliese 832c」が新たに発見されました。しかも、Gliese 832cは天文学的には地球から目と鼻の先の距離にあるとのことです。 The Astrophysical Journal - IOPscience A Nearby Super-Earth with the Right Temperature but Extreme Seaso
(1)はこちら、(2)はこちらから。 App::RunCron (3)では、前回(2)に出てきたcron実行結果の通知処理やエラーハンドリングを統一的に行うことができる拙作のフレームワークApp::RunCronを紹介します。 App::RunCronとは? cronにおけるログとエラーハンドリングの問題点 cronで実行したコマンドのエラー処理は悩ましいところです。パイプで出力を後続のコマンドに渡したところで、コマンドの成否自体は後続のコマンドからは知るすべはなく、出力結果から推測するしかありません。ログ処理とも共通することですが、コマンド終了コードがわからないまま、成功時も失敗時の別なく出力が流れてくることから、ログが埋もれてしまうというジレンマをcronは抱えています。 かといって、ジョブごとにエラー処理を書くのは、正しく書くのも難しく、書けたところで各ジョブ内に同じようなコードが
要約 Chefみたいなスキーマ管理ツール(Ridgepole)を使うと、GitHubを使ったワークフローでスキーマを管理できる(と思います、たぶん) RailsのMigrationsについての問題提起 Migrationsは便利な仕組みですがベストではないと常々思っていました。 具体的には、特定のマイグレーションを保留にしにくいとか、複数人で作業するとコンフリクトすることがあるとか。 大きめのRailsプロジェクトだと特別なワークフローを用意して解決しているんですかね…声出して行こうぜ!とか。 Chef的スキーマ管理ツール: Ridgepole https://github.com/winebarrel/ridgepole (デモ) 以前からそのようなそのような問題意識があって、たぶん Chef的な冪等性保証する(操作ではなく定義を書くたぐいの)ツールがあれば解決できそう、でも実際作るの大
Javascriptを使うのをやめろ:Railsの時代遅れ云々についての結論 - Qiita この記事は、全体的に自分の業務以外の評価基準やトレンドを知らないんだなという感じで、わざわざ付き合うと精神的に消耗する感じがした。ただ、それが彼らの本職でない以上、自分もこの結論に至るのは仕方ないと感じている部分はある。 真の問題は、自分がレガシーなJavaScriptを書いているという自覚がない人間が、ここ数年の技術トレンドから乖離したコードを書き続けることで他のエンジニアやエコシステムそのものに悪影響を及ぼしているケースが散見されている。一行書く毎にグローバル汚染するスクリプトを見せられてもメンテ出来んと言われても、はいそうですねとしか言えないし、そういう人に最近のライブラリを触らせると遅くなるというのは、画面全体を一つのMustacheテンプレートにしてBackbone.Modelのパラメー
以前紹介したghqというツールで GitHub のリポジトリを手元に簡単クローンしてたのを、環境が新しくなったついでに Go で書き直し、完全リニューアルしました。(前は zsh だったのでなんだかなーと思ってた。) そもそも何をするツールか GitHub や Google Code Project でホストされている Git、Mercurial のリポジトリを手元にクローンすることができます。リポジトリは設定したルート(デフォルトで ~/.ghq)以下に、以下のようなパスで置かれます。 ~/.ghq/github.com/motemen/ghq go get と似てますね。同じような感じで ghq get <URL> します。 % ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq ->
June 12, 2014 TL;DR peco入れた。速い peco https://github.com/lestrrat/peco まだターミナルのヒストリの絞り込みぐらいしか使っていないけど便利です。 percol https://github.com/mooz/percol 元々moozさんが書いたpercolというものがあってlestrratさんがGoで書いたものがpeco。 導入方法 peco を go get $ go get github.com/lestrrat/peco/cmd/peco/ .zshrc percolのものを流用させて頂きました。 function peco-select-history() { local tac if which tac > /dev/null; then tac="tac" else tac="tail -r" fi BUFFER
me > hubot cloudfront list distributions hubot > - 0: E2SO336F6AMQ08 -------------------- domain: d1ood20dgya2ll.cloudfront.net status: InProgress comment: Distribution for static.liap.us - 1: E29XRZTZN1VOAV -------------------- domain: d290rn73xc4vfg.cloudfront.net status: Deployed invalidation batches in progress: 10
結論: Javascriptの乱用をやめるのが一番。 はじめに書いておきますがしょうもない話です。 結論、開発者としてはどのような方向性でやるべきか、を書いています。 JS多い時代でのフレームワークの根本的な問題云々のことは書いてません。 さて、現状、モバイルにおいて、Javascriptでまともに動くものを作ることは難しいです。 Twitterから引き抜いた超優秀なWebエンジニアを多数抱えるMediumですら、未だにモバイルで多数のバグを抱えています。 超優秀なエンジニアを世界一抱えているであろうGoogleのGmailですら、モバイル版のWebはすぐクラッシュします。また、自前スクロールに致命的なバグも抱えています。 正確には「UIが不審な挙動をする」ですが、エンドユーザにとっては同じことで、「バグ」です。 サーバサイドで起こるバグと同じ程度、いやそれ以上に、サービスに影響を与えます
はじめに Serfに続いてHashiCorpからConsulが発表されて、2ヶ月少々経ちました。 公式では Serf: service discovery and orchestration Consul: service discovery and configuration と言っていますが(http://www.serfdom.io/intro/vs-consul.html)、Consulも使い方によってはオーケストレーションできるかなと思って、試してみました。 ちなみに Serf や Consul の最近の動向については @zembutsu さんの記事がわかりやすいです ご注文は監視自動化ですか? SerfとConsulの記事まとめ そもそもオーケストレーションとは webサーバをproxyから追加したり抜いたり webサーバにデプロイしたり 障害が発生したサーバを撤去したり db
内閣府ウェブサイトの常時暗号化による「https:」への切り替え Always on TLS of Cabinet Office Website 2019(令和元)年11月更新 Update,November,2019 内閣府ウェブサイトは、2018年11月29日より、常時暗号化通信(TLS1.2)となり、URLが以下のとおり、「https:」に変更となりました。※ ブックマーク機能等に「http:」で始まるURLを登録している場合や、リンクを貼っている場合等は、「https:」から始まるURLに切り替えていただきますよう、お願いいたします。 ※参考:2018年11月から2019年10月までは、httpによる接続を可能とする自動遷移の経過措置をとっておりました。 内閣府ホームページ(https://www.cao.go.jp/) 内閣府共通検索システム Cabinet Office has
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く