サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
ykzts.blog
先日、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
こんにちは@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です。技術書を読まなくてもソフトウェア開発者として働き続けることはできます。 この技術書を読まなければならないといったことを半ば強制的に言ってくる人の言葉には耳を貸さなくても大丈夫です。 もし、強く技術書を買うよう要求してくる人がいるのであればその人に本を買ってもらいましょう。そういうことができるのは若者の内だけです。 技術書を読めと言うのならば、そうした責任を持つべきです。とくに働き始めの人はまだお金も少なく、ほかの書籍と比べると高価な技術書を購入することは難しいのですから。
この記事は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) を使ったインフラ面の構築も行っていました。設立されたばかりで社内にいるソフトウェア開発者の人数が少ない段階で関わることでき、幅広い領域の
最近 fetch API をヘビーに使うようになっていて、いろいろと勘所もわかってきていて、Promise ベースなのはやっぱりすごく便利なんだけれども、現状だと機能が全然足りないなあ、と。 XMLHttpRequestUpload 相当がないのは知っていたし、困ったなあと思っていたんだけれども、XMLHttpRequestUpload 自体がだいぶレア目のヤツで使うような機会もまあめったにないので実害としてはそこまで大きくなかった。 んで、だ、XMLHttpRequestUpload 相当がないのは良いとしても、ReadableStream で XMLHttpRequest で言う progress イベント相当のことをしようとしたときに、発火時にトータルの容量がわからんつう問題が発生した。 fetch API で ReadableStream を使って progress の状況を取ると
2015年11月1日付けで株式会社アニメイトラボにジョインしました。 社員としての初出社日は本日二日ですが、しばらく前からアニメイトラボのオフィスで働いていたため、実感というものは全くありません。なお籍も席もまだピクシブ株式会社に残っており、退職ではありません。なので例の画像 (わからない人はわからなくて構いません) は張りませんので、あしからずご了承ください。 アニメイトラボはその名の通りアニメイトグループに属する会社です。わたし自身のアニメイトに関する思い出や想いを書くと非常に長くなってしまうので省略しますが、わたしはアニメやマンガが好きで、何年も前からアニメイトでの商品の購入をしていました。なので、まさか自分がアニメイトグループの一員になる日が来るとは夢にも思っていませんでした。 わたしが直近行うのはアニメイトラボによるスマートフォン向けアプリの開発と運用になります。スマートフォン向
平成二十六年十月十五日をもちまして、二年強の間勤めておりました会社から退社いたしました。 その会社はウェブアプリケーションの開発を主に行う会社で、業務の大半は受託開発となります。在宅での勤務が可能となっているため、社員各自の自宅が実質的なオフィスとなっています。そのため通勤などで煩わしく感じることがなく、また自己が好ましいと思う環境での仕事がしやすいのではないかと思います。 わたしには合いませんでしたが。 現在、わたしはエオルゼアで調理師をしております。トマトケチャップの生産を繰り返し繰り返し行い、お金をちまちまと貯めております。もらえるものはなんでも欲しいので退職祝いはAmazonのほしいものリストからご遠慮なくどうぞ。
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の言語としての進
HTML.jsというJavaScriptで楽にDOM操作を行えるようにするライブラリーがあります。結論から申しますと、このライブラリーは絶対に使うべきではないライブラリーとなっています。 この記事は執筆時点の最新バージョンであるHTML.js 0.9.3を元にして書いており、今後なんらかの変更がHTML.jsに加えられることによって、次に書く内容は陳腐化してしまう可能性はないわけではありません。ですが、ひとまづこの記事を執筆している時点では使うにあたって不都合ばかりが多く発生してしまう非常に邪悪なライブラリーです。 HTML.jsはMutationObserverを使えるウェブブラウザーではMutationObserverを用いて、MutationObserverが使えない環境ではDOMSubtreeModifiedイベントを用いてHTML文書の変更を検知しています。そしてHTML文書に変
数年前ならいざ知らず、現代のJavaScriptは充分に高速な動作が実現されている。無論C言語で記載されたいわゆるネイティブアプリケーションと比較すれば計算速度等では大きく劣ってしまう。だがしかし複雑な計算等を必要としない通常範囲のアプリケーションであればJavaScript (とHTMLとCSS) で記述がなされたアプリケーションの実行速度はネイティブアプリケーションと遜色ないものになると半ば強い確信を抱いている。ではJavaScriptで記述がなされているアプリケーションの動作が緩慢であるという認識がなぜ多くの場でなされているのか。それは単純な理由である、そのアプリケーションの作者が知識不足でDOM操作が冗長的なものとなっており無駄が多くなってしまっているからだ。 JavaScriptの動作が速くなろうとも、DOM操作は現在でも多くの場面で遅くなってしまっている。document.ge
ここ最近、俄かにSPDYが流行の兆しを見せているように見える。言及されぬ技術は使われず、そして使われぬ技術は存在しない物であるのと同義であると私は考えるので悪い事ではないのだが、本来SPDYを使う上で注意すべきである点を無視して言及しているように見えるので一度深く熟考する必要があるのではないだろうか。 SPDYは複数の要求を一つの接続に纏め上げられる通信規格であり、通常のHTTPによる通信に於いて存在していた大きな速度遅延の要因をなくす事は、確かに出来ている。だがSPDYは規格の仕様上、TLSを上層に配す、HTTPSである事を求められている。HTTPSは暗号化と複合化の処理だけではなく、証明書の確認も行われる事になる為に、HTTPよりも速度は低下する事になってしまっている。数十程度の接続しかなされないようなウェブページであれば、SPDYを使う事によって得られる速度向上よりも、HTTPSを使
さようならHTML5…。アメリカ人と日本人の標準化に差を感じる 内容に関しても思う所は御座いますが、一つだけ。 HTML 5の仕様を現在 書いていらっしゃるGoogle社のIan Hickson氏はアメリカの方ではなくスイスで生まれた方です。現在どちらに住まれているのかは存じませんが少なくとも「アメリカ人」と表現されるような方ではないかと考えます。 またHTML 5は当初はApple社、Google社、Mozillaが共同で設立させた団体であるWHATWGによって仕様が策定されていましたが、現在ではW3Cに移管されています。W3Cは多国籍な団体 (そもそもイギリスで生まれ方が創設した団体です) であり、日本で生まれた方も多く議論に参加なさっています。そもそもApple社もGoogle社も元より多国籍な会社であり、アメリカで生まれた方 以外も多く所属されているように思います。 そしてその仕様
ゲームは基本的にWindows PCでプレイしているのに加えて購入しづらいという話を度々耳にしていたのでPlayStation 5 (PS5) は購入するつもりがあまりなかったのですが2023年夏に発売予定のFINAL FANTASY XVI (FF16) がPS5以外はサポートしないそうなのでPS5を購入しました。
このページを最初にブックマークしてみませんか?
『ykzts.blog | ykzts.blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く