同じ内容qiitaに投稿しても「いいね」0だけどdev.toにpostすると10分でリアクション10付く
dev.toにpostした感想を1行で
バニラJSでajaxを実装してみる
個人的なメモとして残しておく
なぜVaillaJSを使うのか
なぜVanilla JSを使うのかというととにかくパフォーマンスがいいそうで。
下のサイトに書かれています。
http://vanilla-js.com/
爆速で有名のdev.toもVanllaだそうです。
Ajaxを実現してみる
- jQueryの場合
$.ajax({
type: 'GET',
url: '/my/url',
success: function(resp) {
},
error: function() {
}
});
- VanillaJSの場合
var request = new XMLHttpRequest();
request.open('GET', '/my/url', true);
request.onload = function() {
if (request.status >= 200 && request.status < 400) {
// Success!
console.log("成功")
} else {
console.log("失敗")
}
};
request.onerror = function() {
console.log("失敗")
};
request.send();
なにか間違ってたりしたらコメントください。お願いします😓
dev.toにブックマーク機能が実装されました
ソース
これによると記事の下部に新しくしおりアイコンが設置され、クリックするとreadinglistに追加される模様です。
この変更に伴い考えるemojiと両手を挙げるemojiが削除されました。
ただ代わりになるような変更が近いうちにリリースされるようですので期待して待ちましょう
dev.to が β 版ダークモード(Night Mode)を公開し始めたようだ
はじめに
表示速度が爆速で有名なプログラマ向け記事投稿サイト、dev.to。
そのdev.to が β 版ダークモード(Night Mode)を公開し始めたようです。
簡単に内容を紹介していきます。
tl;dr
dev.to にアクセスした後、おもむろに Webブラウザの開発者ツールを開き、Console から以下のコマンドを実行しましょう。
document.body.className = 'night-theme';
するとこの状態から…
ダークモードに変貌します!!!
直接 DOM の body class をいじって切り替えるあたり、β版っぽさというか隠しコマンド感があって良いですね…!
詳細について
以下の記事で紹介されていました。簡単に内容を要約します。
Previewing dev.to's Upcoming Night Mode - DEV Community 👩💻👨💻
- Night Mode はかねてよりあった要望だ
- ずっと backlog の issue に残っていたが、@rkichenama の PR によって動き始めた
- 残念ながら、CSS スタイル自体は未完成。単純に色を反転しただけの状態で、画像もグレースケールになってしまう状態
- しかし、何もない状態よりはずっと良い。Night Mode が利用できるようになったことを嬉しく思う
- 現在テストできないわけではない。β版 Night Mode として、ここから、今すぐにテストすることが可能だ!
すでにこの記事上でもPR上でも、フィードバックが多数飛んでいます…!
終わりに
Contributer がダークモードの PR を出し、未完成でも β版として公開していく dev.to チーム。アップデートの勢いを感じますね。
実際にダークモードを試してみてフィードバックを出してみるのも良いかも知れませんね。
素晴らしい記事
https://dev.to/aspittel/moving-past-tutorials-8-tips-for-problem-solving-3e0p
本文
Trust yourself
Trust yourself to try writing the code without help at first -- you have your pseudocode and have gone through that tutorial. Before you start searching for an answer, trust your intuition and write some code. Then debug it methodologically if needed. Or think through why it isn't working as expected. Don't immediately jump back to the tutorial, Google, or a colleague -- try yourself first. It will have the biggest benefit to your learning process.
日本語訳(グーグル翻訳をちょっと修正)
自分を信頼してください
最初は自分自身を信頼し、助けを借りずにコードを書いてみてください - あなたはあなたの擬似コードを持っていて、そのチュートリアルを通過しました。あなたが答えを探し始める前に、あなたの直感を信頼してそして何らかのコードを書いてください。その後、必要に応じて方法論的にデバッグします。それとも、なぜ期待どおりに機能しないのかを考えてみてください。すぐにチュートリアル、Google、または同僚に戻ることはしないでください - まず自分で試してください。それはあなたの学習過程に最大の利益をもたらすでしょう。
他にもたくさんの内容が書いてあります。ぜひ、サイトの方をのぞいてみてください。
この記事を読むまで、私は自分の記憶力をあてにしていませんでした。すぐにグーグルを頼りました。
なんども検索することで、覚えることはできましたが、それは、早いとは言えませんでした。
最近は、少しでもわかるなら、まずコードを書いてみます。結局のところ、そのあとに、検索しなければいけないことの方が多いので、無駄な時間かもしれません。
しかし、記憶への定着は今の方が早いと感じています。
freeCodeCamp「ブログをMediumから引っ越すわ」dev.to「いや、あかんじゃろそれ」
日本ではあまり目立っていませんが、freeCodeCampというオンライン学習サイトとして世界最大規模のコミュニティが存在します。
規模をわかりやすく言うとGitHubのスター数がトップです。
そしてここはブログ機能があるのですが、記事を自前で持ってるわけではなくMediumを使っていました。
しかし先日2019/05/27に、自ら運営する準備ができたようで、記事をMediumからfreeCodeCamp Newsに移行するという発表を行いました。
以下はそのことについてBen Halpernが書いたI'm concerned with the move that FreeCodeCamp just pulled by leaving Mediumという記事の日本語訳です。
I'm concerned with the move that FreeCodeCamp just pulled by leaving Medium
FreeCodeCampは素晴らしい組織であり、関係者達はみんな崇高な志を持っていると考えています。
しかし彼らが昨日発表したアナウンスと彼らの意図に、私は戸惑い、心配しています。
What they did
FreeCodeCampは、多くの適切な理由により、Mediumから移行したことを発表しました。
開発者コミュニティに伝えたいことを何でも書くことができる、独自のオープンソースパブリッシュプラットフォームがあります。
訪問者はこれまで以上に多くなります。
もうサインインを求めるポップアップで邪魔されることはありません。訪問者は自由にあなたの記事を閲覧することができます。
この移行計画は長期にわたる予定で、まだかなりの数のバグが存在します。
私はかつて、MediumのビジネスモデルやインセンティブとfreeCodeCampのそれのずれについて、懸念を表明したことがあります。
それがdev.toの存在する大きな理由です。
しかし、今回は別の話です。
私の考える最大の懸念は、FreeCodeCampが、Mediumや著作者が暗黙的または明示的に表明している合意条項に違反している可能性のある方法で、この移行をやってしまったのではないかと思われることです。
What I can tell
Mediumに投稿されたFreeCodeCampの全ての記事は、著者の項目がこのように表示されています。
"Visit author's page"を押しても、本来の著者は何処にも表示されません。
実のところ私は、それらの記事の作者がそのコンテンツをMediumから移動させることに同意していないことを知っています。
例えば、以下の記事はまずdev.toに投稿され、Mediumにクロスポストし、FreeCodeCampに公開されました。
Mediumの記事においては、canonical URLはオリジナルであるdev.toの投稿へとリンクされています。
ところが、FreeCodeCampへの移行においてはこの意思が尊重されませんでした。
著者たちに記事の配布場所を提供するサービスの創設者として、このことは極めて深刻な問題であると考えています。
我々は利用規約、そしてFAQにおいて、その姿勢を表明しています。
あなたは、あなたが作成してdev.toに投稿するコンテンツに対する権利を所有し、あなたが適切と考えるように投稿・編集・削除する完全な権限を持っています。
Mediumの規約にも同じようなことが書かれています。
あなたは、あなたが作成してMediumに投稿するコンテンツに対する権利を所有する。
Hackernoonは現在、Mediumからの長期にわたる脱出計画を画策していますが、上記のような問題は全て考慮に入れているようです。
実際、HackerNoonについてMediumは以下のように述べています。
Mediumに関する出版物はMediumの規約によって制限されており、明示的に許可しないかぎり、彼ら(HackerNoon)にはあなたのコンテンツに対する権利はありません。
これには、Medium以外のWebサイトへのコンテンツのエクスポート、コピー、転載などが含まれます。
あなたのコンテンツをMediumから新しいHackernoon.comへ移動したくない場合は、メールに同意しないでください。
あなたの投稿は引き続きMediumで利用可能です。
FreeCodeCampは、全員のMediumのコンテンツを全て抜き取り、正規のURLを削除し、著者から記事の編集・削除・管理能力を奪い取りました。
私が何か間違っているようであれば、コメントで教えてください。
コメント欄
Ali Spittel
私はdev.toで働く前は、自分のブログからdev.toとMediumの両方にクロスポストしていました。
視聴者層の異なる3カ所に投稿することが私の戦略であり、それは非常にうまく行っていました。
そして、そのCanonical URLは私のブログを成長させるために本当に重要でした。
私がFreeCodeCampにクロスポストした投稿のいくつかは、あるキーワードで1位になっています。
もしCanonical URLがなかったら、Gooleはそれをスパムや盗用と考え、コンテンツにペナルティを科すでしょう。
私のコンテンツを読んだ人は、私がコンテンツ作成にどれくらい時間を費やしているか知っているかと思います。
おおむね8から10時間かけて(主に日曜日のレストランで)、そしてそして私はコンテンツをマネタイズしたことは一度もありません。
私の書いた記事がこの新しいサイトに置かれており、私の名前が非常に見つけにくいところにあり、そしてcanonical URLが正しいdev.ioを示していないことに、私は本当にがっかりしました。
壮大な計画の前では、私のキャリアなどたいして重要なことでもないかもしれませんが、しかし、プラットフォームはコンテンツ制作者のことを第一に考える必要があると私は思います。
私はこの新しいサイトが公開されるかどうか、フォーマットがどうなるのか、それともコンテンツを削除するのか、ということも何も知りませんでした。
新しいサイトへの移動の許可を求めるメールを見逃していないか確認するため、受信トレイを何度も検索しましたが、何も見つかりませんでした。
そして、おそらく他の著者に対しても同じことをやっているのでしょう。
HackerNoonがMediumをやめたときにも同じような経験をしましたが、それは非常に異なっていました。
彼らは私のコンテンツを移動する前に、私に許可を求めました。
幸いなことに私の読者はSNS、dev.toと来てSEOは3番目なので、影響はそこまで大きくありませんが、しかし、多くの新人コンテンツ制作者にとってSEOは本当に重要な要素です。
SEOは彼らのブログに注目を集める能力に多大な影響を与えます。
SEOの重要性についてはここで読めます。
Quincy Larson
我々は、既にDan Abramovが述べた理由によってMediumから脱出しなければなりませんでした。
freeCodeCamp NewsはGhostオープンソースプラットフォーム上にあり、非常にパワフルです。
記事へのフルアクセス権を与えるため、全ての著者へとアクセスします。
とりわけ、彼らはcanonical URLを更新し、記事を完全に分析できるでしょう。
これについてもう少し詳しく書きました。https://www.freecodecamp.org/forum/t/279929
我々はオープンウェブの支持者であり、そしてまたdev.toの大ファンです。
我々は、開発者が個人のブログに投稿した記事をクロスポストするもうひとつの場所がfreeCodeCamp Newsになることを願っています。
Ben Halpern
Mediumを辞める理由は知っていて、それについては立派だと思います。
しかし、透明性や同意無しに全員のデータを取り込んでコンテンツを再配布することが最大の問題です。
私は弁護士ではありませんが、膨大なコンテンツを抱える立場にしては、非常に不安定な足場だと思います。
その他
「いや、元のcanonical URLをそのまま使えよ。いちいち著者に変更させるのはどうなんだ。」「Mediumがcanonical URLを設定させませんでした。」「なわけねー。Mediumツールでインポートしたらcanonical URLはちゃんと指定される。」「そのような記事はありますか?」「この記事のAliの投稿がまさにこれ。Mediumではcanonical URLがdev.toになってる。freeCodeCampはなってない。」
「あなたが間違っているとは思わない。」
「私はコンテンツ制作で生計を立てていないが、そうしている人にとって、投稿からcanonical URLが消されたことは気の毒だ。」
「これはひどい・・・何かバグでもないかぎり、あなたが見逃したことがあるとは思えない。」
「この記事を読むまで、canonical URLが何のために存在するのか、本当には理解できていませんでした。」
「Wow!私はfreeCodeCampにたくさん記事を投稿しましたが、まさかこんなことをするとは思ってなかったよ。」
「これは、Quincyに記事をdev.toにクロスポストするよう説得するチャンス!」
「canonical URLを変更できることに驚いた。本人以外はできないと思ってた。」「Mediumに残ってる記事のcanonical URLはそのまま。新サイトにコピペされた記事のcanonical URLが書き換えられてる。」
解説
最初の記事は、元々外部サービスを使っていたところを、自分のところで運用することにした、という発表です。
これ自体はまあ、それまでYoutubeを使っていたニコニコ動画が自社でストレージを持つようにした、みたいなものでたいした話ではありません。
問題は、それに伴って『記事をMediumからfreeCodeCampにコピペした』『canonical URLを自サイトに書き換えた』『しかも著作者に無断で行った』というところです。
ニコ動の例で言うなら『Youtubeに上がっていた動画をニコ動にコピーした』『著作者表示を自分の名前に書き換えた』『しかもアップロード者に無断で行った』みたいなものです。
どうしてそれで問題が起こらないと思ったのか。
まず記事の表記名として、MediumのfreeCodeCampページでは各投稿者が投稿している記事が、freeCodeCamp上では全てFREECODECAMP.ORGが投稿したように見えています。
さすがに問題がありすぎたためか、この表示は早々に修正されました。
修正する前に、コメント欄でそのうち修正するとか言ってたんだけど、どう考えても公開前にやっておくべきことだったことだろ。
さらに問題なのはCanonical URLを勝手に書き換えていることであり、これは出自を奪い取るだけではなく、SEO的にも問題になります。
freeCodeCampは元々検索に強いこともあり、freeCodeCampの記事が優先され、元記事であるはずの本人のブログのほうが盗用扱いされてランキングが下がってしまう可能性が高いでしょう。
これらの問題について、本人が記事を修正できるようにすると言っていますが、修正するにはfreeCodeCampアカウントを作れとか巫山戯たことが書いてあってこりゃひでえ。
最初からオプトインにしておけば何の問題もなかったのに、オプトアウトにしたせいで問題噴出ってことですね。
感想
コメント欄にいるAli Spittelは、dev.toの中の人であり、本文中の例で出てくる"The most important non-programming skills for programmers"の記事を投稿した人です。
Quincy LarsonはfreeCodeCampを作った人です。
そして、この記事の著者Ben Halpernってのは誰なのかというと、dev.toを作った人です。
そりゃ懸念も示すわってかんじですね。
あとQuincy Larsonのコメントはなんか全体的にピント外れで、大丈夫なのかこの人?
やってる人と取り上げてる人からいって、もっと騒動になってもおかしくなさそうなのに、今のところだいぶ全体的に静かです。
現状これについて取り上げているメディアは、英語圏含め存在しないようです。
しかし今後の舵取り次第では激しく燃えそうな気配です。
果たしてどうなるでしょうか。
ちなみに途中で出てくるHackerNoonはこのあたりの話です。
ざっくり言うと、HackerNoonも同じようにMediumからの脱出を図っているけど、オプトインを選んだから同意しないかぎり記事が勝手に移動されることはないよ、というものです。
なお、個人的には、clap数表示がなくなった時点で魅力9割減。
Qiitaもですが、なんで一覧ページから評価を消すんですかね?
2019年の残り期間で学習するべきスキル
Gatsby?ああ、MovableTypeの翻案ね(間違い)
以下はMarc Grabanskiによる記事、What Front-End Developer Skills Should You Focus on Learning for the Rest of 2019?の日本語訳です。
What Front-End Developer Skills Should You Focus on Learning for the Rest of 2019?
こんにちは、私はFrontend MastersのCEO、Marcです。
このたびdev.toコミュニティのスポンサーになれることを嬉しく思います!😀
JavaScript and Front-End Engineering
我々は、地球上で最も急激に変化し、進化する、そして最も活発なコミュニティのひとつに居ます。
JavaScriptはES6以降、毎年多くの進化をし続けています。
Node.jsが現れて以来、多くの企業がサーバでもJavaScriptを使い始めました。
フロントエンドWeb開発者は、ツールやビルドツール、フレームワークの進化と共に変化し、進化し続けています。
その最先端の一部はWeb AssemblyとReact Hooksで、我々がやがて何を作り出せるかを見るのが楽しみです。
さて、2019年の残り時間に集中して学習すべきスキルは何でしょうか。
以下では3カテゴリに分けて紹介します。
Begin Coding Now
これからコーディングを始める人。Becoming a Professional Front-End Developer
フロントエンドエンジニアのプロフェッショナルになりたい。Becoming a Well-Rounded Engineer
フルスタックエンジニアになりたい。
1. Begin Coding Now
手短に言うと、最初に正のフィードバックループを手に入れることが最も重要です。
何かを変更して、そうしたらすぐにその結果がわかる、ということです。
Get Started: Scratch, HTML/CSS/JS or Python
始めよう。Scratchでも、HTML/CSS/JSでも、Pythonでも。
私は、どの言語やツールからプログラミングを始めるかは問題ではないと考えています。
それがScratchでも、HTMLでも、CSSとJavaScriptでも、Pythonでも、あるいは何らかのフレームワークであっても。
大事なのは、正のフィードバックループを確立し、アイデアを構築し、プログラミングに興味を持つことです。
2. Becoming a Professional Front-End Developer
Mastering the Fundamentals of JavaScript
JavaScriptの基礎をマスターする。
Frontend Mastersは、JavaScriptの基礎とプログラミングパラダイムは、普遍的なものであると信じています。
スコープとクロージャの仕組み、プロトタイプシステム、および型システムは、あなたのキャリアにおいて何度も何度も学習することが必要になるでしょう。
Know Your Paradigm: Functional and Object Oriented Programming
自分のパラダイムを知ろう。関数型?オブジェクト指向?
JavaScriptはマルチパラダイム言語であるため、オブジェクト指向と関数型パラダイムの両方を学習することで、より高次のレベルに到達しやすくなります。
オブジェクト指向は大規模なアプリケーションを構築する一般的な手法です。
その次は関数型からmap、reduce、filter、純粋関数、コンポジションといった概念を取り込みましょう。
最後に、オブジェクト指向と関数型をどのように使い分けるかを身につける必要があります。
React or Vue?
プロフェッショナルなコードを素早く作成したい場合、最も早い方法はReactやVueといったフレームワークを使うことです。
大抵の仕事では、これらトップフレームワークの少なくともひとつを深く知っていることを要求されます。
多くの知識人は私がAngularに言及しなかったことに反応するかもしれません。
しかし、Angularは初めて扱うのに適したフレームワークだとは思いません。
なんでもかんでも入ってる、という思想を活かすのに十分な規模のプロジェクトは、最初のうちはやってきません。
Developer Tools
開発者ツールの使い方を習得し、コードをデバッグし、アプリケーションのパフォーマンスを向上させましょう。
TypeScript
開発者のエクスペリエンスを向上させるためにTypeScriptを導入する企業は年々増加しています。
CSS Grid and Flexbox
CSS GridとFlexboxは、あらゆるデバイスで動作するレスポンシブWebサイトをレイアウトするために不可欠です。
Webpack
Create React AppやParcelといったツールは導入を簡単にしてくれますが、より詳しくなるためにはWebpackを学んでください。
出力コードを最適化するためのカスタムビルドを作成しましょう。
3. Becoming More Well-Rounded
Design Skills
基本的なデザインスキルを手に入れることで、より望ましいオールラウンド開発者になることができます。
Node.js & Full-Stack Deployment.
Node.jsを学び、APIを構築する方法を学び、フルスタックエンジニアになりましょう。
アプリを自分でセットアップ・デプロイできるなら、さらに応用範囲が広がります。
現在はアプリのデプロイ先としてAWSが最も勢いのあるプラットフォームですが、Azureも人気を集めつつあります。
SVG
最も能力に秀でていて、そして最も活用されていないグラフィックフォーマットのひとつがSVGです。
モバイルデバイスから看板サイズまで自在に拡縮することができる、非常に優れた形式です。
Testing
壊れたコードを作っていないことを保証したいですか?
Jestのようなテストランナーでテストを行い、壊れたデプロイを防ぎましょう。
Git
コードを失った?
あなたがGitマスターであれば、コードを失うことは決してなく、マージ時に問題が発生したとしても復旧することができます。
Gitのエキスパートは、開発チームの全員から崇拝されるでしょう。
Computer Science
計算量の求め方を計算し、正しいアルゴリズムとデータ構造の使い方を知ることで、エンジニアリング思考力を育て、より効率的なソリューションの開発ができるようになります。
Accessibility
WebサイトとWebアプリケーションがあらゆる人に開かれていることを確認するために、アクセシビリティの理解は重要です。
またナビゲーションにキーボードだけを使用するようなパワーユーザも満足させます。
Newer Skills
高パフォーマンスなWebサイトを作るため、Gatsbyが市民権を得つつあります。
ブラウザで3DのCanvasとWebGLが広くサポートされたため、ブラウザ上でクリエイティブコーディングが可能になりました。
GraphQLはRESTのようにAPIを複数のエンドポイントに分けるのではなく、クライアント側で欲しいデータを正確に指定できるため、APIの柔軟性を高めることができます。
2019年残りの期間に開発者が学ぶべきだと、あなたが考えるスキルは何ですか?
コメント欄
「アマ開発者とプロ開発者の境目はテストだと考えているので、全ての技術スタックでテストを考えるべき」「同意しかない。しばしばテストは後回しにされるけど、TDDは実際最優先されるスキルになりつつある。」
「ここ最近で学習コースを一通り渡り歩いて、FEMは私の人生に必須のツールボックスになったよ。」「それは良かった!あなたのキャリアに幸ありますように!」「あとフロントエンドハンドブックも手放せない。」「ナイス!2020年版も既に作り始めてるよ!」
「現在TypeScriptコースを受講してる。満足したらテストコースやCSコースも受けたい、楽しみ。」
「基礎を全く持ってない人はLinkedInやUdemyのような初心者コースから始めたほうがいい?」「FEMはまさにあなたのためのコースも用意してるよ!ラーニングパスも参考にしてね。」
「Svelteコースがみつからなかった。今後追加される予定はありますか?」「作者のRich Harrisと何かするつもりだけど、まだ決まってないんだ。」
「Accssibility!」「追加した!」
「Flutter…まだモバイルだけだけど、WebバージョンのHummingbirdが近付いてる。Dartはよいぞ。」
「JAMStackとサーバレスにも言及が必要。」
感想
FrontendMastersはフロントエンド中心の学習コースを提供しているサイトです。
費用は月$39
、年間$390
と決して安くはありませんが、評判は悪くないようで、特に中上級者向けだそうです。
英語のヒアリングが苦にならない人は試してみてはどうでしょうか。
それ以外の活動としては、毎年Front-End Developer Handbookを発表しています。
フロントエンドについてはかなり最強に近いところではないかと思います。
そんなところが勧めるのですから、半分はコースの宣伝だったとしても、学習方針としては適切な方向性を向いているのではないでしょうか。
コースを受講するかどうかは別として、出てきた技術を学習することは決して悪くないと思います。