Semgrep CodeFind and fix the issues that matter in your code (SAST)
Semgrep CodeFind and fix the issues that matter in your code (SAST)
リストアップしてみての感想 ミドルウェアや言語処理系ではまだまだC言語が広く使われている。特に2014年に登場したh2oがCで書かれているのは特筆するべき。 最近のミドルウェア/処理系ではC++を使っているケースもちらほらある。代表例はChrome,MongoDB,node.js,HHVMなど。 Java製ツールは(自分の身近には)あまり多くない。embulkがJava製なのは要注目。 2009-2013年あたりに登場したインフラ系プロダクトではRuby製が多い。ただ最近ではGoに押され気味。 2013年以降、Go製のツールが急に増えてきた印象がある。 各言語について思うところ (特定の言語をDisる意図はありません) C 既存ミドルウェアでC製のものが多いので、トラブルシューティングをしたりパッチをあてたりするにはC言語とその周辺ツール(make,gdb,lddなど)の知識は必要。 スク
{{getAnalysisToolsText()}} Yamllint TSLint tfsec SwiftLint stylelint StyleCop ShellCheck Scalastyle RuboCop Revive Pylint pycodestyle PSScriptAnalyzer PHP_CodeSniffer TSQLLint lintr HLint Brakeman bundler-audit Checkstyle CodeNarc CoffeeLint Linter for Dart CppLint Detekt ESLint Flawfinder Vet Hadolint CSSLint Bandit .NET assembly informer Duplication checker
オラクル、JavaやJavaScript、Ruby、Pythonなど多言語対応を単一ランタイムで実現する「GraalVM」をオープンソースで公開。Twitterが本番環境で採用 JavaやJavaScriptなどには、それぞれその言語を実行するためのランタイムが存在します。JavaならJavaVM、JavaScriptならJavaScriptエンジンといった具合です。 米オラクルがオープンソースで公開した「GraalVM」は、これまで言語ごとに個別に用意されていたランタイムを統合し、単一の高性能なVMにするという同社の研究の結果開発された汎用仮想マシンあるいは汎用ランタイムです(米オラクルのブログ、日本語訳)。 GraalVMのWebサイトには、次のような説明が記されています。 GraalVM is a universal virtual machine for running appli
参加したイベントのメモです。 イベント概要 【CTO meetup】Rust,Go,Elixir,Kotlin次世代言語の魅力をCTOが語る 2018/04/12(木) 19:00 〜 23:00 https://flexy.connpass.com/event/82063/ 言語選定について サーバーが2種類あった。 使う言語を統一していこう→トップダウンでElixirに決まる。 1200台のサーバーを4人で運用。自動化しないと無理。 →GOで自動化(現場発信) Elixir使いたいとは思っていたが、ずっと使えずに居た。 Railsで何のチューニングもなしだとパフォーマンス問題。 →Elixirだと何のチューニングもなくても10倍は違う。 APIサーバー ユーザー情報保存 ユーザーのストレージ情報 書き換え用API マルチバトルサーバー ずっと接続しっぱなしのサーバー。 言語はC#, R
最近、TypeScriptについて考えることが多い。SideCIでWebフロントエンドの開発に使いはじめたこともあるし、Steepの開発をしていて「TypeScriptだとどうなるんだっけ??」などと言いながら試してみることもある。 TypeScriptは型付きのJavaScriptである。構文はほとんど同じで、使えるライブラリもかなり近い。JavaScriptへの変換はかなり自明で、ランタイムは全く同じ。性能の差はない。Webpackやnpmを初めとするツール群もかなり共通しているし、アプリケーションも似たようなもん。書いている気分には、ほとんど差がない。つまり、TypeScriptとJavaScriptでプログラミングしているときに、なにか違いを感じるとすれば、それは(ほとんど)型付きの言語と型なしの言語の差と考えて良い。 RubyとJavaを比較するのとは、全然話が違う。構文も意味も
エンジニアの大橋 @_tohashi です。会計freeeで確定申告や記帳機能などの開発を担当しています。 Webに限らず、日本向けのアプリケーションにおける特有の要素として和暦があります。プロダクトによっては最初から和暦を扱わずに西暦に統一してしまうという手もありますが、弊社のプロダクトのように会計や労務管理に関わるものの場合、決算書上の表記など和暦が必要とされる場面は多々あるため避けて通ることはできません。本記事ではUIや実装における和暦の扱いについてご紹介したいと思います。 和暦の範囲 そもそも「和暦」とはどこからどこまでの期間を指すのでしょうか。Wikipediaによれば 和暦(われき)は、元号とそれに続く年数によって年を表現する、日本独自の紀年法である。邦暦(ほうれき)とも。また「和暦」は、西暦に対する表現としても使用されることが多い。 この手法自体は東アジアで広く行われてきたが
昨年の5月からIncrements社でQiitaの開発に従事していましたが、今月末をもってIncrements社を退職します。在籍期間は10ヶ月。今日が最終出社日です。 Incrementsでは、Qiitaの機能追加開発を主に担当していました。Qiita Blogには、僕がリリースしてきた機能が掲載されています。 yoichiroがIncrementsにJOINしました - Qiita Blog Email Markupに対応しました - Qiita Blog 外部リンクへの属性が変わります - Qiita Blog (僕が実作業者) Qiita Organizationで組織の紹介などを書ける「About」の提供を開始しました - Qiita Blog details,summary要素に対応し、投稿内で指定箇所を折りたためるようになりました - Qiita Blog 「Qiita Ad
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか? どの例外をキャッチし、どの例外を伝搬させればよいだろうか? 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか? 例外をどういう単位でラップさせるのが良いだろうか? 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
世界初のプログラム内蔵方式コンピュータに搭載された、最初のプログラムを書くのに使われた言語は何だったでしょうか? もちろん、バイナリの機械語です。 なぜですか? えー、当然ながら、シンボリックアセンブラがなかったからです。最初期のプログラムは、バイナリで書かなければなりませんでした。 バイナリの機械語と比較して、アセンブリ言語でプログラムを書くと、どのくらい簡単ですか? ずっと 簡単です。 数字を言ってください。何倍ぐらい簡単ですか? えー、まあ、アセンブラは、あなたの代わりに面倒な事務処理を全てしてくれますからね。つまり、全ての物理アドレスの計算です。全ての物理的な命令を構築するわけです。あなたが範囲外にアドレス指定するなど、物理的に不可能なことをしないよう確認します。そして、簡単にロードできるバイナリの出力を生成します。 それによって、軽減されたワークロードは、 膨大 です。 どのくら
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
C や C# そして Ruby や Java などでは、実数を整数に丸める際、 単純にキャストしますと切り捨てますが、 round 関数で丸める際に、挙動が異なります。 Python: Ruby: C#: (自作のシェル経由でごめんなさい) C や Ruby, Java では四捨五入がデフォルトで行われますが、 C# では、銀行丸めがデフォルトで行われます。 正式名称は 「最近接偶数への丸め」と言いますが、 「銀行丸め」のほか、「JIS丸め」「ISO丸め」とも言われます。 [Wikipedia の解説記事] JIS丸めとは? http://homepage1.nifty.com/s_miyake/hp/jisround.htm JIS Z 8401 http://www.jisc.go.jp/app/pager?id=94037 上の記事の文章を用いて、簡単に説明すれば、 N桁で丸める場合
地道にバージョンアップを繰り返しているUser-Agentパーサライブラリの woothee ですが、このたび 1.0.0 をリリースしましたのでお知らせいたします。 http://woothee.github.io/ 今回は前からやろうやろうと思ってたOSバージョンのparseをサポートしました。特にスマートフォン(iOS/Android)のバージョンが気になる人が多いようで、手元でもあったらいいなというケースが多くなってきたため、えいやと入れました。 ただし今回はあまり時間がなかったので、とりあえず自分で使いそうな以下の言語のみリリースしています。 Java Perl Ruby Javascript (npm) PHP (10/28追記 対応されました) 以下の言語についてはまだ対応していません。誰かPull Requestを送るといいと思います。 Python Golang 現状こん
概要 1582年10月5日〜1582年10月14日までの10日間は、何らかの自然現象(ゴゴゴゴゴ)によって時間が消し去れてた期間として知られています。プログラミング言語を使ってこの日を取り扱おうとすると、いろんな結果が出力されます。 今日はそんな素敵な日付である1582年10月5日と戯れて、貴重な1日を無駄にしてみたいと思います。 Java とりあえずJavaから。バージョンは7。 // 1582/10/05をパース Date dt1 = new SimpleDateFormat("yyyy/MM/dd").parse("1582/10/05"); System.out.println(dt1); // 1582/10/04をパース Date dt2 = new SimpleDateFormat("yyyy/MM/dd").parse("1582/10/04"); System.out.p
webrubyはWebブラウザ上で動作するmrubyです。 mrubyは組み込み用として開発されたミニマムなRuby実行環境ですが、ミニマム故に使いどころが色々とありそうです。今回はなんとWebブラウザ上で動作するmruby、webrubyを紹介します。 WebGLを使うデモ。 結構ぐりぐりと動きます。 FPSも53とあって滑らかです。 こちらはirbです。コードを書いてその場で実行して結果を得られます。 確かにちゃんと記述できます。 普通にmrubyです。 以前に紹介したJsMrubyの場合は機能拡張としてインストールされるものでしたが、webrubyの場合はemscriptenを使ってmrubyのソースコードをJavaScriptに変換しているのが特徴です。まだまだおもちゃレベルとのことですが、今後発展すると面白いプロジェクトになりそうです。 webrubyはJavaScript製のオ
README.md Project Woothee Project Woothee is multi-language user-agent strings parsers, now contains perl and java implementations. Why new project? We needs just same logic over 2 or more programming languages, for use on various frameworks, middlewares and environments. Most important data of this project is only single set of return values, and set of test cases, for equality of results of anot
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く