恭喜, 站点创建成功! 这是默认index.html,本页面由系统自动生成 本页面在FTP根目录下的index.html 您可以修改、删除或覆盖本页面 FTP相关信息,请到“面板系统后台 > FTP” 查看
Jupyterはすごい便利なんですが、この機能があったらなーと思うことがあります。 そんなときにはextensionです。 JupyterにはNotebook extensionsとかいうのがあって、機能の拡張ができるようになっています。 公式サイトにもextensionsがあるということはちょこっと載ってるんですが、いくつか使用してみると結構便利。 Jupyterは使っているけどextensionは使っていないというひとに是非試して欲しいです。 Jupyter notebook extensions Jupyterに機能を追加するextensionを集めたレポジトリがGitHub上に公開されています。 このレポジトリを利用すると、ブラウザからextensionのactivate/deactivateの切り替えが可能で便利です。 IPythonの公式デベロッパーチームとは関係ないグループで
はじめに 2016年2月22日(日本時間23日未明)、IBMのクラウドプラットフォームBluemixがSwiftに対応したことを発表しました。加えて、Kituraと呼ばれるSwiftのWebアプリケーションフレームワークがOSSとして公開されました。 IBMによるSwift関連の取り組みはオフィシャルサイトとGithub上のリポジトリで確認することができます。 https://github.com/IBM-Swift https://developer.ibm.com/swift/products/kitura/ なぜIBMはSwiftを選ぶのか? Swift@IBMのQuestions and Answersで、What is Swift?という問いに対して、以下のように答えていることから、Swiftを将来性のあるプログラミング言語と捉えて、自社のプロダクトに採用しているのだと思います。
MacPorts と比べて Homebrew は依存関係でインストールされるソフトが少ないためか、パッケージ管理システムとしての人気が高まってきています。 MacPorts は、Mac に最初から入っているソフトウェアを無視してパッケージが依存するソフトを新規でインストールするという性質を持っていますが、Homebrew は極力 Mac に入っているものを使うように作られています。ゆえに、パッケージ導入時のシステムへの負担や、インストールにかかる時間が比較的少なくて済むようです。 また、Homebrew はスーパーユーザでコマンドを実行する必要が無く、一般ユーザー権限で使うことが出来ます。 ※【2015/07/07 追記】最近では Homebrew が大きく台頭してきて、MacPorts の名前を見ることは減ってきました Homebrew について Homebrew は「ユーザが自らパッケ
2016 - 02 - 05 GithubとbitBucketに対応しているCIツールwercker 思考の整理 開発 Docker この記事はWIPです BitbucketにCIを導入しようということになってwerckerを実装したのでまとめておきます。 色々とネットにある情報を見ながら実装したのですが、まずサービス自体が日本語対応していません。 また、Qiitaやブログにある情報も少なく、かつ2014年の頃の物が多くて2016年2月現在では仕様変更により変わっている部分も多く戸惑いました。 なのでこれからwerckerを使ってみようという方は情報の正確性に注意しながら実装してください。 なお、今回この記事を書く上で以下の記事を参考にさせていただきました。 これらの記事はとても参考になりました、ありがとうございます。 Werckerの仕組み,独自のboxとstepのつくりかた |
CI サービスをいくつか触ってみたのでまとめ。 今回の目的は、テストを実行すること。なので、ビルドやデプロイ辺りはちゃんとは見ていない。 ドキュメントで確認しただけの項目などもあったりするので、間違っていたらごめんなさい。教えてもらえると助かります。 ただ、これは記事を書いた時点での比較で、今後のサービスの変更に対応する予定はないです。 触ってみたサービス一覧 アルファベット順。 AppVeyor CircleCI Drone IO Magnum CI semaphore shippable Travis CI wercker codeship ってのもあったけど、無料プランは月100ビルドまでとかで常用には耐えないと感じたので中身見てない。 機能比較 機能比較は全て無料プランでのもの。有料だと対応している場合でもここでは x にしている。 比較項目は私の独断と偏見で適当に選出した。 項目
CMake/C++ プロジェクトについて GCC または Clang のバージョンに併せた最新の -std オプションを与える CMake の記述例C++GCCCMakeclangC++1z if( CMAKE_CXX_COMPILER_ID MATCHES "Clang" ) if( CMAKE_CXX_COMPILER_VERION VERSION_GREATER 3.5 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 3.5 ) set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++1z" ) elseif( CMAKE_CXX_COMPILER_VERION VERSION_GREATER 3.2 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 3.2 ) s
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって(それなりにスペック高くて、slaveもぶら下がってる)、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く