Selenium API(逆引き) 利用目的からSelenium APIを探せます Selenium Java(ABC順) ABC順にJavaのSelenium APIを探せます Selenium Python(ABC順) ABC順にPythonのSelenium APIを探せます Selenium Ruby(ABC順) ABC順にRubyのSelenium APIを探せます Appium API(逆引き) 利用目的からAppium APIを探せます
Fatal error: Uncaught Google_Service_Exception: Error calling GET https://www.googleapis.com/analytics/v3/data/ga?ids=ga%3A138132118&start-date=7daysAgo&end-date=yesterday&metrics=ga%3Apageviews&dimensions=ga%3ApageTitle%2C+ga%3ApagePath&sort=-ga%3Apageviews&max-results=40: (403) User does not have sufficient permissions for this profile. in /home/users/1/monda-muki/web/seleniumqref.com/google-api
Laravelで開発しててDIコンテナに出くわし、そういえばRailsで開発していてDI利用したことなかったなと思ったので、なぜRuby(Rails)でDIが一般的ではないのかのまとめる。 TL;DR Rubyはインスタンスへの依存性も動的に変更できるから基本的にDI不要 ほぼ下記記事参照なので、英語できる人はこっちの記事をどうぞ LEGOs, Play-Doh, and Programming DI DI(Dependency Injection)は依存性の注入とよばれるインスタンス間の依存性を解消する技術。外部から依存するインスタンスを注入できるのでテストのときにモックオブジェクトの差し替えなどで便利。またDIフレームワークはDIコンテナにインスタンスの生成と注入を任せることで疎結合・高凝集を実現するテクニックである。 ネイティブアプリ(iOSは知らない)だと一般的に使われている技術で
「Java捨ててC#にでも振ったほうがいいのかなあ」 なんて聞かれ、 「nodeとかあるしJSのがまだマシじゃないすかね、というかOracleから逃げた結果がMS行きってどうなんすか」 とか答えたあと、もう少し考えてみたほうが良さそうだなあ、と思ったので考えてみる。 なお、筆者は諸事情でこれまでJava仕事が多かった人種ではあるものの、基本的にJava嫌いかつOracle嫌い1であるため、考察には強いバイアスが掛かっている可能性が高いことを申し添える。 TL; DR 「Javaは捨てたほうがいいんじゃないのか」という発想は間違っていないが、性急、または手遅れである。 そもそも特定言語一本で行くような無茶をしてはならない。また今回みたいなことになりたいんでなければ。 Javaの強み 「Javaの強みはなんですか?」 たぶん、Javaの草創期は「オブジェクト指向」が上がったのではなかろうか。
皆さんがせっかく作った Ruby Application, どうせなら色んな人に使ってもらいたいと思いませんか? とはいえ, Ruby User には gem install hoge してくださいと言えば伝わるものの,非 programmer の user にはそうはいきません.一般 user からすれば, .exe 形式や .app 形式でないとちょっと敷居が高いと思います. それなら, Rawr を使って, Ruby Application を .exe 化, .app 化しましょう! note: Web 上に Rawr に関する記事はいくつか見つかりましたが, gem library を require するような Application をパッケージ化する方法については,正しく動作するようなものが見つからなかったため,記事にまとめることにしました. Requirement JRu
普段はVisualStudioCodeでRailsのコードを書いているのですが、Rubyのフォーマッターがほしいと常々思っていました。 そこで、週間Railsウォッチで紹介されていたRufoというRubyフォーマッターを使ってみたところ、非常に使いやすく、自分の使い方にもマッチしていたので紹介します。 変更点 2018/09/30 Setting.mdに合わせて設定の内容を更新しました。 設定できる項目が減り、いずれ設定をする必要がなくなるようです。 細かく設定したい人にはうれしくない話かもしれませんが、フォーマットは統一できればさほど問題ないので、細かく設定できて差分が生じるより良い話かと思います。 フォーマッターに求めること 自分がフォーマッターに求めることは主に以下の4つです。 保存時に自動でフォーマットがかかること フォーマット設定が容易で、共有できること ストレスなく使えること
最近、エディタをSublime TextからAtomに変えました。もともと、エディタにはそんなにこだわりはなく、変えた理由もAtomがいいという声を聞くようになったからという単純なものです。 AtomもSublime Textと同じように”パッケージ”をインストールすることで様々な機能を追加することができます。これで自分が使いやすいエディタに進化させていくわけですね。 今回はソースコードを自動で綺麗に整形してくれる”atom-beautify“というパッケージを試してみました。 対応言語はHTML、CSS、Java、Rubyなど atom-beautifyのWebサイトから引用しますが、以下に示したように多くのプログラミング言語に対応しています。一部の言語においては別のツールをあらかじめインストールしておかなければいけない場合があるそうです。 Beautify HTML, CSS, Jav
オブジェクト指向にもとづくクラス構造を、本来異質なRDBのテーブル構造に対応させることをOR(Object-Relational)マッピングといい、そのための仕掛けがORマッパーである。代表的なものがHibernateやJPAで、これらを使うことは、WEBアプリ界隈では常識といっていいものになっている。しかし、これを業務システム開発で利用するのは、特別な事情がない限りお勧めできない。 ORマッピングの技術は良いものと悪いものとをもたらした。良いものとしては、Ruby on Railsのような生産性の高い開発環境を挙げられる。じっさいRailsは、TwitterやGithubといった優れたサービスの基礎として社会に貢献した。いっぽう、業務システム開発の世界に対しては、ORマッパーはどちらかといえばハタ迷惑な影響ばかりをもたらしたと言わざるを得ない。テーブル構成が比較的単純に済むWEBアプリを
コードのインデントはタブ?スペース? クォートはシングル?ダブル? 人気のあるコーディングルールの統計 -Popular Coding Convention
Swaggerを使ってAPI定義をしてスタブを動かしてみます。 Swaggerの関連ツールは様々な言語に対応していますが、ここではNode.jsを使って試してみます。 Swaggerとはなんぞ? Swaggerは関連ツールが多くあるので全容がつかみにくいのですが、 What is Swagger? The goal of Swagger™ is to define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network
背景 最近は変化し続ける要件に対応するために、システムも柔軟であることが求められています。 そのため、部分的に変更やスケールの可能なシステムを構築し、API経由で連携するマイクロサービス的アーキテクチャが増えてきています。 そういった設計の中で問題になっていくのが、従来のモノリシックなアプリケーションではIDEやコンパイラなどで行っていた、機能間のインターフェイスをどう管理するかという部分です。 Swaggerとは? SwaggerとはRESTful APIのドキュメントや、サーバ、クライアントコード、エディタ、またそれらを扱うための仕様などを提供するフレームワークです。 公式サイトでは、The World's Most Popular Framework for APIsと謳っています。 その理由は、マイクロソフト、Google、IBM、SmartBearなどを大手の企業を含む「Open
API Development forEveryone Simplify your API development with our open-source and professional tools, built to help you and your team efficiently design and document APIs at scale. Find your toolRead the docs Trusted by Empowering API Development Streamline your workflow with unparalleled API specification support Swagger places API specifications such as OpenAPI, AsyncAPI, and JSON Schema at the
デジタルビジネス時代を迎え、API連携へのニーズがこれまで以上に高まっている現在、API仕様を管理するOSSフレームワーク「Swagger」(スワッガー)が大きな注目を浴びています。本連載では、同フレームワークの未経験者・初心者を対象に、その概要や基本的な使い方を解説していきます。 仕様と実装の乖離が許されないAPI システム開発のトレンドとして、マイクロサービス化が進んできています。モノリス(一枚岩)スタイルの開発に比べて、アプリケーションの単位は小さくなり、多くのサービスが構築されます。 Uberの配車ビジネスやAirbnbの民泊に代表されるデジタルビジネスにおいても、APIエコノミー化が進んできており、Google Map APIやTwitter APIなどさまざまなAPIを組み合わせて素早くシステムを構築します。 Programmable Webでは、2017年1月時点で16,59
下記のような文字をいくつかのプログラム言語の標準的な API で URL (URI) エンコードしてみたらどうなるか試してみました。 ; / ? : @ = & % $ - _ . + ! * ' " ( ) , { } | \ ^ ~ [ ]使用した言語は下記の通りです。 Groovy (Java API) C# (.NET Framework) JavaScript Ruby Python PHP ソースは http://github.com/fits/try_samples/tree/master/blog/20130425/ Java の場合 Java では下記メソッドが使えます。 java.net.URLEncoder の encode() メソッド 今回は Groovy で実装してみました。 url_encode.groovy str = ';/?:@=&% $-_.+!*\'
README h�P�U �[�P�U 鍵生成はPKCS#5のPBKDF2、HMAC SHA1です。 暗号化はAES、CBC mode、鍵長128bit、iteration count 65536です。 パスワードは「password」固定、saltは長さ8 octetで0x0001020304050607(Big Endian)です。 ivの長さは128bit固定です(なんで固定なのかよくわかってない)。 送信するメッセージは、iv:encrypted_messageの構成です。先頭16 octetがiv、残りが全部encrypted_message。 Javaでもっと長い鍵を使うにはUnlimited Strength Jurisdiction Policyが必要です。http://www.oracle.com/technetwork/java/javase/downloads/jce
Rubyで暗号化したデータをJavaで復号化、またその逆を行ってみた。 今回はAES128ビットの暗号化モードCBC、パディングはPKCS#5で実施。 まずRuby側のコード。 require 'openssl' require 'base64' class CryptUtil def self.encrypt(pass, value) enc = OpenSSL::Cipher.new('aes-128-cbc') # 暗号化or復号化どちらを行うかセット(今回は暗号化)、復号化の場合はdecrypt enc.encrypt # ivを生成 iv = OpenSSL::Random.random_bytes(16) # 暗号化する際のキー文字列をセット enc.key = pass # ivをセット enc.iv = iv crypted = "" crypted << enc.upda
DI の自由度は諸刃の剣 近ごろ、「実プロジェクトでDIコンテナ(注1)を導入している」という話をちらほら耳にするようになりました。それと同時に、「DIコンテナを使ったプロジェクトが大変なことになっている」という話も耳にするようになりました。DIの魅力を十分に享受して低コスト、高品質を実現しているプロジェクトがある一方で「DIを導入してみたのはいいのだけれど、DIの設定ファイルが大きくなりすぎて管理しきれない」「DIを使っているのに、テスタビリティが全然向上していない」など苦労しているプロジェクトもあるようです。この差はいったいどこから来るのでしょうか。 DIは、EJBなどと比べると比較的取っ付きやすい技術ではありますが、ほかの技術同様、誤った使い方では十分に力を発揮できません。DIコンテナは非常に単純明快な技術ではありますが、そのシンプルさ故に自由度が高くさまざまな使い方ができます。その
PHPでアプリケーションを作ってゆく。大きくなると、classが増えてゆく。classが増えてゆき、constructorの引数が増えてゆく。classをnewする順番が決まってゆき、それに従はねばならない。同じインスタンスがあちこちで必要になる。DI (Dependency Injection, IoC) の出番だ。 はじめはPimpleを使うてゐたが面倒になり、既存のDIライブラリは複雑な手続きが必要で、面倒だったので自分で作った。Ranyuen/Diだ。 cf. Ranyuen/Di https://github.com/Ranyuen/Di cf. PHPで簡単に華麗にDIとAOPをキメる http://c4se.hatenablog.com/entry/2014/12/11/013136 こんなに苦労して作ったDIコンテナだが、Rubyでは20行で書けるとMatzも言ってゐる。
あけましておめでとうございます。 大晦日は実家でプログレ聞きながらコード書いてました。 今さらながら Heldon の Stand by とか聞いてたんですが、Tangerine Dream を思わせるミニマルなシンセサイザーの反復と、リシャール・ピナスによるロバート・フリップばりの暴力的なギターソロが絡みあっており、大変良いですね。 作ったもの また説明長くなりそうなので、はじめに作ったものの紹介です。 dee dee-rails この Dee というのが DI コンテナの本体です。 名前は Ozzy Osbourne ソロ 1st Blizzard of Ozz におけるランディ・ローズのギター曲からです。 50 秒と短く、メタルアルバムの中にあってクラシック風の静かなギター曲ですが、同時にアルバムから欠かせない存在感を放つ名曲です。 何が言いたいかというと、Dee はコンパクトな実装
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く