サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
ykzts.blog
表題の通りw3c-xmlhttprequest v3.0.0をリリースしました。細かなバグの修正や最新のXMLHttpRequestの仕様に追従させたりと様々な変更が含まれていますが一番大きな変更としてはECMAScript 2015からTypeScriptへの移行でしょう。 v1.0.0をリリースしたのが2012年なので当初はECMAScript 5を前提としていました。Object.keysやObject.defineProperty、JSON.parseといった当時としては新しい機能を使っていましたがどうしても古さは否めず2016年にECMAScript 2015に書き換えたv2.0.0をリリースしていました。とはいえvar文をlet文とconst文に置き換えたり、prototypeプロパティーをclass構文に置き換えたりといった基本的なところの書き換えしかしておらず根本の部分は2
先日、Mastodon Developers Kaigi #0というカンファレンスの開催をしました。こうしたカンファレンスの主催をするのは初めてでしたが多くの方の協力によって大きな問題も起こることなく、とても意義のあるカンファレンスにできました。 「Mastodonについて技術的な側面から語る発表を聴きたい」というわたしの個人的な思いによって開催したカンファレンスでしたが、多くの人に来ていただきとてもうれしかったです。 Mastodonの開発が始まったのは2016年からです。そして日本で話題になった2017年4月からも半年も経っていません。Mastodonはまだまだ若い技術です。今後も大きく伸びていくものであるとわたしは直感しています。 今後もこうしたカンファレンスの開催を継続的に行っていけたらと考えています。 もし興味を持たれたかたがいらっしゃいましたらぜひご参加ください。発表をする方も
四月の半ばからMastodonへのコントリビュートを繰り返していたところ、今月の24日にmasterブランチへmergeする権限をいただきました。 現状では言語追加といった本体の動作に影響を与えないPull Requestのmergeのみを行っています。それ以外の機能追加やバグ修正、デザインの変更などといったものは基本的にMastodonのAuthorであるGargron氏に委ねるという方針でいます。テストの追加やリファクタリングに関しては臨機応変に見ていこうと考えています。 現状のわたしのMastodonへのコミット数は205です。これに加えてMastodonに寄せられたPull Requestsに対してコードレビューをいくつかしています。 検証用にVPSでインスタンスを立てたりと現状は大赤字の状況です。わたしのMastodonに対するコントリビュートを応援してくださる方向けにFanti
山岸和利は JavaScript や Ruby を用いたウェブアプリケーションの開発を得意とするソフトウェア開発者です。ほかにも Go や Perl、Python も扱います。Ruby on Rails や React に造詣が深く、多くのウェブアプリケーションの開発を行っています。バックエンドからフロントエンドまで幅広く担当します。またウェブアプリケーション以外にも React Native を使ったスマートフォン向けアプリケーションの開発も行えます。ウェブ関連の技術を中心とした学習を意欲的にしています。 さらに Amazon Web Services (AWS) や Google Cloud Platform (GCP) といったクラウドサービスを利用したインフラストラクチャーの構築も得意としています。ウェブアプリケーションやウェブサービスの開発に関わる多くの領域の作業ができるという自
こんにちは@ykzts@ykzts.technologyです。気付けばMastodonへのコミットの数が100を超えていました。公式にもPull Requestのレビュワーにも任命されて、Mastodon関連で少し忙しくなっています。 さて、技術情報共有サービス「Qiita」を運営するIncrements株式会社が先日Mastodon インスタンス「Qiitadon」を公開しました。 わたしはQiitaをそこまで活用しているユーザーではありません。ですが、Qiitadonでは投稿に含まれるコードにシンタックスハイライトを施す機能をMastodonに追加しているとのことで少し興味が惹かれました。MastodonはAGPLで提供されているOSSであるため、そのカスタマイズ版であるQiitadonもソースコードがGitHub上で公開されています。 コードを確認してみたところ、Mastodon v
Mastodonについての話題がここ数週間の内に破竹の勢いでかけめぐっています。ここまでの勢いというのはTwitterができたばかりの2007年のころが思い起こされ、とてもなつかしい気持になっています。 Mastodonとの出会い わたしがMastodonのアカウントを作ったのは日本で話題になり初めた四月十一日の夜遅くであり、少し遅いです。前職の同僚と飲んでいる際に話題となって、その場でmastodon.cloudにアカウントを作りました。その後、日本人が多くいるという話を聞いたmastodon.nil.nu (現 mstdn.jp) にアカウントを移して、mstdn.jpでの二度のデータベース削除の末にPawooに落ち着きました。 結果としてわたしとMastodonアカウントは@ykzts@pawoo.net、@ykzts@mstdn.jp、@ykzts@mastodon.cloudの
わたし自身が優秀なエンジニア (ソフトウェアエンジニア) であると他者から評価される、されないといったことは正直 興味を抱くところはない。評価とかを気にすることなく自身が興味を抱いた技術についてひたすら知識を深めていくだけである。 だが、自分では自分のことを優秀だと思っているし、優秀だと言うようにしている。 雇ってもらおうと思い、企業の面接に行くときは当然 自己のPRをする。もちろん嘘を吐くことはないし、そもそも嘘は吐きたくない。なのでやってきたことや、やりたいことを正直に言うだけではある。そこで自分が優秀であり採用することによって、どのような利を得られるかと説明する。 そのわたしの説明を聴いて (「聞いて」ではないはずだ) 納得をした上で採用してくれた人がいる以上、わたしがわたしのことを優秀ではないと言うのはその人たちに対する裏切りでしかない。 そんな不誠実は、わたしはしたくない。わたし
わたしがソフトウェア開発者として働くようになってからもう何年も経ちますが、通読した技術書は0です。技術書を読まなくてもソフトウェア開発者として働き続けることはできます。 この技術書を読まなければならないといったことを半ば強制的に言ってくる人の言葉には耳を貸さなくても大丈夫です。 もし、強く技術書を買うよう要求してくる人がいるのであればその人に本を買ってもらいましょう。そういうことができるのは若者の内だけです。 技術書を読めと言うのならば、そうした責任を持つべきです。とくに働き始めの人はまだお金も少なく、ほかの書籍と比べると高価な技術書を購入することは難しいのですから。
tweet receiverというウェブアプリケーションを作りました。 Twitterでフォローしている人のツイートをUser streamsを介して取得し、それをWebSocket (RFC 6455) を経由させてリアルタイムに表示させるだけの機能しか有していません。ツイートを投稿することはできませんし、できるようにするつもりも今の時点ではありません。純粋に人のツイートを見るだけです。 User streamsを活用したウェブアプリケーションを別に開発していて、その検証のために簡単なものを作ろうと思って作り始めたものです。ですが、動かしてみたところ思ったよりも便利なので、もう少し見た目の体裁を整えて常用に耐えるものにしようと考えています。
この記事はhttp2 Advent Calendar 2016の二十三日目の記事である。 今年……2016年はHTTP/2が大いなる躍進を遂げた年であったと感じる。 Amazon CloudFrontも今年の九月にHTTP/2の対応が追加された (Amazon CloudFront now supports HTTP/2)。またFastlyでも十一月から一般利用が可能となった (HTTP/2 is now in General Availability)。 これまではNginxやApache HTTP ServerなどのHTTP/2に対応したHTTPサーバーをフロントとして自身で運用しなければならなかった。Contents Delivery Network (CDN) サービスの恩恵を享受できず、また運用の手間をかける必要もあった。 しかし今年 多くのCDNサービスがHTTP/2に対応した
現在有休消化期間中ですが、2016年十二月三十一日をもってピクシブ株式会社を退職します。ピクシブに入社したのは2014年十二月です。まるまる二年、勤めていたことになります。 二年の内、2015年十一月から2016年十月までは株式会社アニメイトラボに出向していて、またピクシブに入社してからアニメイトラボに出向する以前もアニメイトラボの仕事のお手伝いをしていました。そのため実はピクシブの仕事自体はほとんどしていません。 アニメイトラボではアプリケーションエンドエンジニアとしてフロントエンド (JavaScript、CSS、HTML) からサーバーサイド (Ruby、PHP、Node.js) まで触っていて、またAmazon Web Service (AWS) を使ったインフラ面の構築も行っていました。設立されたばかりで社内にいるソフトウェア開発者の人数が少ない段階で関わることでき、幅広い領域の
最近、TVを作っています。TVといっても映像を受信して映す機械を作っているわけではありません。TVのように映像を再生して、見ることのできるウェブサービスを開発しています。 そのウェブサービスの名前はBaberuTVです。その名前の通りにbaberu.tvというドメイン名で公開しています。 公開しているとはいえ、まだ開発者であるわたしが日常的に使って困ることが程度の機能がようやく実装しおえたという段階です。使いかたの説明はまだなにも用意できていません。見た目もまだ洗練させられていませんし、おいおい進めて行こうと考えています。 BaberuTVとは 名前の由来はバベルの塔です。天にも届く技術力を得たいというわたしの個人的な思いを込めた命名です。 正しいスペリングである「Babel」ではなく「Baberu」としているのは、かたかな語のようなチープさを出したかったためです。またGoogle検索な
一つのサーバーに複数のドメイン名のウェブページを同居させることはよくある話だと思います。負荷のことを思えばドメイン名単位でサーバーを分けたほうが良いのでしょうが、さしたアクセスが見込めないウェブページを集約しても問題は起きないでしょう。 ただ www. つきでアクセスされた際に、www. なしのドメイン名へのリダイレクトをさせる処理をドメイン名単位で一つ一つ書いていくのは無駄です。 nginx の server_name ディレクティブでは正規表現を使えます。nginx が正規表現エンジンとして使っている PCRE では名前付きキャプチャに対応しているので次のように書けます。 server { listen 80; server_name "~^www\.(?<naked_domain>.*)$"; set $proto $scheme; if ($http_x_forward
最近 fetch API をヘビーに使うようになっていて、いろいろと勘所もわかってきていて、Promise ベースなのはやっぱりすごく便利なんだけれども、現状だと機能が全然足りないなあ、と。 XMLHttpRequestUpload 相当がないのは知っていたし、困ったなあと思っていたんだけれども、XMLHttpRequestUpload 自体がだいぶレア目のヤツで使うような機会もまあめったにないので実害としてはそこまで大きくなかった。 んで、だ、XMLHttpRequestUpload 相当がないのは良いとしても、ReadableStream で XMLHttpRequest で言う progress イベント相当のことをしようとしたときに、発火時にトータルの容量がわからんつう問題が発生した。 fetch API で ReadableStream を使って progress の状況を取ると
近年 エンジニアの採用においてGitHubのアカウントの提出を求められる企業が増えつつあります。それに対して採用の場で個人的な活動の結果を求めるのかと憤る人もいます。 たとえばデザイナーの採用でポートフォリオの提出が必須とされていることは多くあります。それと同様にエンジニアの採用でGitHubのアカウントとそこから見ることのできる成果物の提出を求めることに対する違和感はないのではないかと思います。 GitHubではなく、Bitbucketでも構いません。公開されていなくても良いでしょう。USBフラッシュメモリーやCDなどの光学メディアに入れられたソースコードでも問題ないでしょう。 エンジニアは一部の例外を除けば守秘義務の元で開発をしていることが大半です。ソースコードは基本的に外から見られません。なのでGitHubといった場で公開されているものがあると助かるのです。 ただなにも見えない状態で
2015年11月1日付けで株式会社アニメイトラボにジョインしました。 社員としての初出社日は本日二日ですが、しばらく前からアニメイトラボのオフィスで働いていたため、実感というものは全くありません。なお籍も席もまだピクシブ株式会社に残っており、退職ではありません。なので例の画像 (わからない人はわからなくて構いません) は張りませんので、あしからずご了承ください。 アニメイトラボはその名の通りアニメイトグループに属する会社です。わたし自身のアニメイトに関する思い出や想いを書くと非常に長くなってしまうので省略しますが、わたしはアニメやマンガが好きで、何年も前からアニメイトでの商品の購入をしていました。なので、まさか自分がアニメイトグループの一員になる日が来るとは夢にも思っていませんでした。 わたしが直近行うのはアニメイトラボによるスマートフォン向けアプリの開発と運用になります。スマートフォン向
iPhoneとiPadのシステムソフトウェアをiOS 6.0にアップデートしたところ、Safariのデバッグコンソールを表示する方法を見付けられなくなってしまった。Webインスペクタというのが追加され、Mac OS X上で動作するSafariがあれば効率良くデバッグ出来るようになったようなのだが、非常に残念な事に現在の私の手許にはMac OS Xの環境が存在しない。なのでiOSのSafariでのデバッグが出来ないようになってしまった。探せば既存のデバッグコンソールを表示する方法があるのかも知れないが、しばらく探しても見付ける事が出来なかったので、非常にその場凌ぎの解決法で済ませた。 <script type="text/javascript"> window.addEventListener('error', function(error) { var result = document.
最近になって気がついたがBlobBuilderインターフェースが非推奨となっていた。Chronium 21.0.1180.75にてnew WebKitBlobBuilder()といった記述のあるスクリプトを実行すると「BlobBuilder is deprecated. Use “Blob” constructor instead.」といった表示がコンソールに出力されるようになっている。まだ現時点では使えはするようだがいつ使えないようになってしまうのかわからない。なのでつかうようにと表示されているようBlobはどういった仕様でどのようにつかえるものなのかを簡単に調べてみた。 File APIの仕様中にあるBlobインターフェースの項を見てみたところ var blob = (function(blobBuilder) { blobBuilder.append('<!doctype html>
去年の末ごろからピクシブ株式会社で働いています。 当初の予定かんがえではキリが良く四月一日に長めの記事を書くつもりだったのですが、いろいろとあって記事を書く余裕がなく、このままずるずる延ばしても忘れるだけなので、とりあえずの記事を上げます。 Amazon Whishlist はこちらにまとめてありますので、お手隙の方は気軽に物品の贈答をしてくださりますとさいわいに思います。
平成二十六年十月十五日をもちまして、二年強の間勤めておりました会社から退社いたしました。 その会社はウェブアプリケーションの開発を主に行う会社で、業務の大半は受託開発となります。在宅での勤務が可能となっているため、社員各自の自宅が実質的なオフィスとなっています。そのため通勤などで煩わしく感じることがなく、また自己が好ましいと思う環境での仕事がしやすいのではないかと思います。 わたしには合いませんでしたが。 現在、わたしはエオルゼアで調理師をしております。トマトケチャップの生産を繰り返し繰り返し行い、お金をちまちまと貯めております。もらえるものはなんでも欲しいので退職祝いはAmazonのほしいものリストからご遠慮なくどうぞ。
(function() { 'use strict'; var XMLHttpRequest = require('w3c-xmlhttprequest').XMLHttpRequest; var req = function req(uri) { var client = new XMLHttpRequest(); client.open('GET', uri); client.responseType = 'json' client.addEventListener('load', function(event) { console.log(client.response); }, false); client.send(null); }; req('http://example.com/sample.json'); })();
CoffeeScriptの関数は明示的にreturnするべき 「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは? という両者相反する内容の記事がございました。両論もっともな内容であり、また実行速度だけではなく思想も絡んでしまう非常に煩わしい問題であります。 はじめに筆者の立場を明確にしておきます。筆者は日本国内で働くウェブアプリケーション開発者です。主にウェブアプリケーションフレームワークとしてRuby on Railsを使用しており、それによりCoffeeScriptも日常的に使用し、そして記述しております。 筆者にとってのJavaScriptという言語は、プログラミングというものを深く学ばんと思わせる契機となった言語であり、深い愛着ととともにわずかながらも執着のようなものを抱いております。そのためJavaScriptを
nginxで任意のHTTPヘッダーを追加したい場合にはadd_headerディレクティブを用いますが、add_headerディレクティブは追加しようとしたフィールド名が重複するHTTPヘッダーが既に用意されていた場合には既にある物に「,」区切りで連結してしまいます。たとえば強制的に出力するContent-Typeを変更するためにadd_header Content-Type text/css;のようにしてもContent-Type: text/html, text/cssといった形の不正なHTTPヘッダーが出力されてしまいます。 解決方法は簡単でHTTP Headers More Moduleのmore_set_headersディレクティブをつかえばすぐです。使い方も簡単でadd_headerディレクティブをつかっている箇所をそのままmore_set_headers "Content-Ty
iBus 1.5がクソすぎるという記事がございました。iBusはGNU/LinuxなどのUnixに似た環境を提供するOSのGUIで専ら使われるインプットメソッド (IM) の一つです。iBusはオープンソースソフトウェア (OSS) として提供されており、Google CodeのProject Hostingを用いた管理がなされており、そちらからダウンロードすることができます。 わたしが実際にiBusを使っていた時期というのは決して長いものではなく、また今回「クソすぎる」と強い言葉で否定されてしまっている1.5はまだ使っておりません。ですのでiBusに関して詳しいことを話すのは避けますが、OSSに対して「クソすぎる」というような表現を用いるのはいかがなものかと思ってしまいます。 OSSに対するcontribute、貢献というものはパッチを送り、そのパッチが適用されることだけではないとわたし
モダンな言語でHTML5を開発しよう! 俯瞰して理解するaltJSの比較 (前編 - TypeScript, CoffeeScript, Hexe) と題する記事があった。この記事は見出し中にある「HTML5を開発しよう」という言葉からして意味が通っていない。だが記事の内容から「HTML 5を始めとし、CSSやJavaScriptといったウェブ関連の技術を用いたアプリケーション作りをしよう」という意図であろうと類推することができる。しかしこの記事で問題なのはそのような重箱の隅を突くが如き枝葉末節な部分ではない。この記事の中で薦められているいわゆるaltJSと称される複数の言語たちではない、JavaScriptという言語はモダンな言語ではない、つまり近代的な言語ではないと断言してしまっていることである。 ここ数年のHTML5やCSS3の劇的な進化に比べて、JavaScriptの言語としての進
はてなブックマークの人気エントリーをながめていたところJavaScriptでアニメーションを書く初歩の初歩のような記事が目にはいりました。初歩であればこそ、この記事で省かれているrequestAnimationFrameの話をするべきではないのかとも思いますが、それよりもわたしは元の記事に掲載されているコードがJavaScriptを用いて十ミリ秒の間隔を開けて複数の処理を何度もウェブブラウザーにさせてしまっていることが気になりました。また、いくつかの処理を完了させてから、setTimeoutを用いて任意の時間が経過するのを待ち、同様の処理を行うというかたちになっていますので、処理に時間がかかってしまえば、なめらかな描写は到底実現されないものとなってしまっています。 昨今ではウェブブラウザーの動作させる少なくない端末が高速な処理をなせるようになってきているとはいえ、依然全てがそうなっていると
HTML.jsというJavaScriptで楽にDOM操作を行えるようにするライブラリーがあります。結論から申しますと、このライブラリーは絶対に使うべきではないライブラリーとなっています。 この記事は執筆時点の最新バージョンであるHTML.js 0.9.3を元にして書いており、今後なんらかの変更がHTML.jsに加えられることによって、次に書く内容は陳腐化してしまう可能性はないわけではありません。ですが、ひとまづこの記事を執筆している時点では使うにあたって不都合ばかりが多く発生してしまう非常に邪悪なライブラリーです。 HTML.jsはMutationObserverを使えるウェブブラウザーではMutationObserverを用いて、MutationObserverが使えない環境ではDOMSubtreeModifiedイベントを用いてHTML文書の変更を検知しています。そしてHTML文書に変
w3c-xmlhttprequest 1.1.0をリリースしました。ソースコードはGitHubにございますので、よろしければご確認ください。またPull Requestは熱烈に歓迎いたします。 拙作、w3c-xmlhttprequestはNode向けに書かれたXMLHttpRequestの実装です。できる範囲でW3CによるXMLHttpRequestの仕様にそわせられるように書いてあります。直前のバージョンである1.0.0までではイベントハンドリングの扱いが粗雑なものとなっておりましたが今般のバージョンである1.1.0ではW3Cの仕様に比較的忠実なものにできたのではないかと思います。イベントハンドリングの動作を仕様に忠実にさせるためにDOM 4のイベント周りの実装を簡易的にではありますが、実施しておりますので、ソースコードの方も確認してもらえると、わたしの努力が身を結ばれたように感じられ、
数年前ならいざ知らず、現代のJavaScriptは充分に高速な動作が実現されている。無論C言語で記載されたいわゆるネイティブアプリケーションと比較すれば計算速度等では大きく劣ってしまう。だがしかし複雑な計算等を必要としない通常範囲のアプリケーションであればJavaScript (とHTMLとCSS) で記述がなされたアプリケーションの実行速度はネイティブアプリケーションと遜色ないものになると半ば強い確信を抱いている。ではJavaScriptで記述がなされているアプリケーションの動作が緩慢であるという認識がなぜ多くの場でなされているのか。それは単純な理由である、そのアプリケーションの作者が知識不足でDOM操作が冗長的なものとなっており無駄が多くなってしまっているからだ。 JavaScriptの動作が速くなろうとも、DOM操作は現在でも多くの場面で遅くなってしまっている。document.ge
次のページ
このページを最初にブックマークしてみませんか?
『ykzts.blog | ykzts.blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く