並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 355件

新着順 人気順

mizchiの検索結果81 - 120 件 / 355件

  • コードとビジュアルの双方向編集なエディタを試作して ビジュアルプログラミングについて考えてみた

    ノーコードは形を変えた現代の RPG ツクールなのではないか - mizdev の記事では、ノーコードのビジュアルプログラミングが発展性を欠く理由として、次の理由を挙げました。 汎用的なビジュアルプログラミング基盤(Scratch みたいなものではなくプロユースなもの) ↑ 上でのビジュアル環境でのデータベースのグラフ構造のビジュアル化手法 ↑ 上でのビジュアル環境でのパイプラインのビジュアル化手法 ↑ 上での UI とデータと UI のマッピングのビジュアル化手法 これらを隠蔽してオートスケールするマネージレスなインフラ基盤(これはパイプライン実装の中身) で、こんなものを作った話 現代の Intellisense + Formatter 感覚 TypeScript の補完と、保存の度に prettier をバリバリに効かせた状態でプログラミングをしていると、そもそも自由文脈でコードを書

      コードとビジュアルの双方向編集なエディタを試作して ビジュアルプログラミングについて考えてみた
    • React Hooks + Redux Hooks + TypeScript で SPA を構築する(追記あり) - 30歳からのプログラミング

      2020/05/31 追記 勉強や経験を重ねた結果、この記事を執筆した時より知識が増え、コードの書き方にも変化があります。 サンプルアプリも同様で、以下のプロダクトのコードのほうが、今の自分の考えが反映されていると思います。 github.com 追記終わり 2019/07/14 追記 ディスカウント後の価格みたいな導出項目はselector (reselect)を使うとよいのでは https://redux.js.org/recipes/computing-derived-data - YonmanHasse のブックマーク / はてなブックマーク というコメントを頂き、確かに便利そうだったので導入した。 それに合わせてこの記事の内容もアップデートした。 追記終わり タイトルに書いた組み合わせで SPA を作るときにどのような設計にするのか、現時点での考えを記録しておく。 チュートリアル

        React Hooks + Redux Hooks + TypeScript で SPA を構築する(追記あり) - 30歳からのプログラミング
      • OSS活動と好きな技術が新しいキャリアを切り開いた ー 活用も進む注目のDeno開発企業で私が働く理由 - Findy Engineer Lab

        Webのフロントエンド開発言語として真価を発見されたJavaScriptは、数年後に今度はサーバーサイド開発言語として再発見されます。しかし、その立役者となったNode.jsの作者ライアン・ダール(Ryan Dahl)はNode.jsの開発を離れ、新しいJavaScript実行環境としてDenoを生み出しました。 ▶ Deno - A modern runtime for JavaScript and TypeScript 今回お話しを伺った日野澤歓也(@kt3k)さんは、2018年からオープンソース活動としてDenoにコントリビュートを重ねた結果、作者のライアン・ダール自身にリクルーティングされ、2021年1月にその開発会社であるDeno Land Inc.にジョインしました。現在はフルタイムのOSS開発者として勤務しています。 JSConf JP 2021における日野澤さんの発表「De

          OSS活動と好きな技術が新しいキャリアを切り開いた ー 活用も進む注目のDeno開発企業で私が働く理由 - Findy Engineer Lab
        • フロントエンドの情報収集について - Qiita

          2020/07/17: いくつか追記しました はじめに 私は、TechTrainでフロントエンドのメンターとして面談する中で「最近フロントエンドの勉強を始めました!」という方や、フロントエンドエンジニアを目指す学生と話す機会が何度もあります。 その中でよくある質問が 「フロントエンドの情報収集ってどうしてますか?」 です。 何度も質問を貰うので、気になる人は多いのかなと思います。 この記事では「私がどんな風に情報収集しているか」を紹介しようと思います。主に情報収集の流れと、どこからフロントエンドの情報を集めているかについてです。 情報収集の流れ まずは情報収集の流れとして主にプロセス的な観点で整理してみます。 私の情報収集を抽象化すると以下の3つのプロセスがあると思います。 情報源から情報を集める(ex: Twitter, Blog, Qiita) 特定の場所に情報を溜める(ex: はてな

            フロントエンドの情報収集について - Qiita
          • React.js: The Documentaryで振り返るReact普及の歴史 - laiso

            www.youtube.com Meta(当時Facebook)のReact Core Teamの主要人物たちに直接インタビューしたドキュメンタリー動画 タイムライン 2012年まで 最初はFacebook社内でReactが普及するまでの道程。 当時世の中的にはクロスブラウザの解決策はjQueryに落ち着き、モバイルアプリ化の流れでAPIサーバーとViewは切り離される傾向にあり、JavaScriptのクライアントサイドで大きいアプリケーション作るためにMVCフレームワークとか取り入れないとね〜という雰囲気だった Facebook社はマーク・ザッカーバーグがHTML5に賭けていた頃*1にBolt.jsというFacebook版Backbone.jsを開発していた 広告プラットフォームのコードは当時Bolt.jsを中心に構成されていたが、Jordan Walkeが関数型プログラミングのアイデア

              React.js: The Documentaryで振り返るReact普及の歴史 - laiso
            • Railsの未来についての一考察 - okuramasafumiのブログ

              概要 前置き この記事はRails Advent Calendar 2020の15日目の記事です。昨日はnegito6さんの忙しい人のための Rails デバッグ方法まとめでした。 動機 うなすけさんのRailsを主戦場としている自分が今後学ぶべき技術について(随筆)という記事と、それに対するmizchiさんのアンサーブログ、Re: Rails を主戦場としている自分が今後学ぶべき技術についてに触発されて書いています。 お断り この記事ではRailsの技術的な側面を意図的に重視していません。というのは、私がRails以外の技術についてそこまで詳しくないため比較するのが困難だからです。 また、ふわっとした話題を扱うということもあり、どうしても書き方が推測多めになってしまっています。これは私の知見と経験の少なさによるものです。 本編 アプリケーション開発のマトリックス いきなりですが、アプリケ

                Railsの未来についての一考察 - okuramasafumiのブログ
              • GitHub Actions 使ってみた感想 - mizchi's blog

                やっときたので使ってみた。 CI マニアから見た GitHub Actions(Beta)の使い所 - くりにっき https://github.com/mizchi/frontend-gh-action-playground で素振りして挙動を確かめた後、会社の結構重めのリポジトリに突っ込んでみた。まだ 2 日目なので、実際そこまで経験値足りてない。 とりあえず困ったらここ読む GitHub Actionsのワークフロー構文 - GitHub ヘルプ 良い点 sue445 さんの記事でも書いてあるが、ジョブが 20 個まで並列になるので、並列に分解できるようなものに強い。 GitHub に完結してる点。checks タブで CI の結果が見える。 circleci.com/dashboard とか行かなくていい。外部 CI はアカウント取得やらリポジトリごとの設定やらなんやらもあるので、

                  GitHub Actions 使ってみた感想 - mizchi's blog
                • 映画「ジョーカー」読みごたえのある感想・考察ブログを集めました【ネタバレ】 - 週刊はてなブログ

                  2019年10月4日に日米同時公開となった映画『ジョーカー』が大ヒットしています。 この投稿をInstagramで見る ワーナー ブラザース ジャパンさん(@warnerjp_official)がシェアした投稿 - 2019年10月月3日午後8時07分PDT 「バットマン」シリーズで最大にして最凶の宿敵といわれる“ジョーカー”の誕生を描いた本作。これまでのアメリカン・コミックを原作とした映画とは全く異なり、正義のヒーローが登場せず、貧困や格差の残酷さを真っ向からとらえた壮絶な内容は、公開1週間を待たず世の中の話題をさらいました。 wwws.warnerbros.co.jp はてなブログにも、『ジョーカー』についてのさまざまな感想・考察エントリーが数多く投稿されています。この記事では、その一部をピックアップしてご紹介。ひとりではとらえきれない劇中のシーンやせりふの解釈について、はてなブロガー

                    映画「ジョーカー」読みごたえのある感想・考察ブログを集めました【ネタバレ】 - 週刊はてなブログ
                  • 2021年現在Vueを選択すべきでないと思う理由 感想

                    JSXが嫌でReactを使わないならSvelteがあり、SvelteはゼロオーバーヘッドでVueより速い コンポーネントが作られたり消されたりするような場合一定の閾値でVueの方がバンドルサイズが軽くなる [Draft]VueとSvelteのサイズを比較検証した「vue-svelte-size-analysis」を掘っていく とはいえエッジケース 〇〇倍速いみたいなやつ、知覚したことない(フレームワークパフォーマンスを気にする前にやるべきことが沢山ある) ほぼラインタイムを消し去りたい、20kb未満のアプリケーションを作る必要があるとかだとSvelteは強そう https://zenn.dev/mizchi/articles/8a017097d3994ddc0a85 Next、NuxtのようなSSR/SSG用途で十分に使われてるようなフレームワークがまだない SvelteKit(Svelt

                      2021年現在Vueを選択すべきでないと思う理由 感想
                    • Denoのフロントエンド開発の動向【2021年春】

                      はじめに ここ最近、Denoのフロントエンド向けのエコシステムについて、色々試してみたり、調査などをしていました。 そこで、この記事では、2021年現在のDenoのフロントエンド開発の状況であったり、所感などについてまとめます。 フレームワークについて Node.jsにおけるフロントエンド開発では、以下のフレームワーク[1]が使われることが多いと思います。 React Vue.js Preact これらのフレームワークは、すでにDenoでも動作します。 またこれらをベースにしたフレームワークがいくつか開発されています。 Aleph.js Aleph.jsはNext.jsに影響を受けたReactベースのフレームワークです。 以下のような機能が提供されています: HMRをサポートするdevサーバを提供 ファイルシステムベースのルーティング SSR/SSGをサポート CSS Modules 開発

                        Denoのフロントエンド開発の動向【2021年春】
                      • MoonBit が WebAssembly 時代の理想(の原型)だった

                        最近 moonbit という言語を知ったのですが、これが調べれば調べるほど好きになる言語だったので、紹介させてください。 文法的には GC 付きの Rust で、 WebAssembly にコンパイルされます。とくに CDN Edge Worker 上での実行を想定しているようです。もう好き。 注意: まだ若い言語なので、これから言語仕様がガンガン変わっていくと思われます。あくまで現時点での情報です。 tl;dr Pros だいたい GC あり Rust と捉えていい 文法面のキャッチアップが容易 ライフタイムの難しさを考えなくていい すでに vscode 拡張やパッケージマネージャ等のエコシステムが整っている Cons まだ安定していない / しばらくはソースコードが公開されない 現時点では学習リソースやパッケージ数が足りず、書き手の腕力が求められる はじめに: JS/TS/Rust へ

                          MoonBit が WebAssembly 時代の理想(の原型)だった
                        • 極限環境で最終ビルドを絞るためのフロントエンド設計

                          https://3rdpartyjs.connpass.com/event/289558/

                            極限環境で最終ビルドを絞るためのフロントエンド設計
                          • Incremental Static Regeneration で実現する次世代のサーバーアーキテクチャ

                            next.js 9.4 に Incremental Static Regeneration という実験的な新機能があります。 Blog - Next.js 9.4 | Next.js パッと見、「段階的な静的サイト生成…?なんのことだろう…」となったのですが、手元で試してみた感じ、これが既存のサーバーの実装アプローチを変える、革命的な機能ではないかと思いました。 解説を書きつつ、どのような応用があるか解説します。 next.js の Incremental SSG を試してみる リポジトリはここです。 mizchi/issg-playground 解説にあたっては、必要なのはほぼこのファイルだけで、短いのでそのまま貼ります。 // pages/[slug].tsx import { GetStaticProps, GetStaticPaths } from "next"; type Pro

                              Incremental Static Regeneration で実現する次世代のサーバーアーキテクチャ
                            • プログラムによるレイアウト制御のための CSS Grid を考える

                              この記事は、既存のCSSのレイアウトの文脈ではなく、「プログラムから制御されるレイアウト」をいかに綺麗に制御・生成するか、です。 複雑なSPAや何らかのオーサリング環境で、主に JavaScript の視点からレイアウトを扱うのに Grid をどう活かしていくか、という話。 grid-template-areas の視覚的な対応 IEがない世界では CSS grid のフル機能を使うことができます。 自分が grid を使う際、今まで grid-template-areas を気に入って使っていました。これは CSS の視覚的な情報が最終的な表示と一致する、という理由からです。 例えば、 svelte で書いた grid-template-areas を使ったレイアウト設定のコードはこんな感じになります。。 <div class="grid"> <div style="grid-area:

                                プログラムによるレイアウト制御のための CSS Grid を考える
                              • Svelte + TypeScript のベストプラクティスを考える

                                自分で Svelte + TypeScript を色々と書いてみたが、情報がまとまってなかったので、ここでまとめていく。 なぜ Svelte + TypeScript か Svelte + TypeScript はセマンティクスが単純で型が付く軽量な Vue として気に入っている。ビルドが軽量で他と混ぜやすいのが特に気に入っていて、React や Vue の他のシステムに対しても、末端のコンポーネントとして混ぜやすい。Vue は歴史的経緯でデータバインディングの仕様が混沌としているが、Svelte はESM First で構文解析時の処理に仕様を寄せてるので、とてもシンプル。 webcomponents として配布するモードがあるのも気に入っている。Vue React は単体のビルドサイズが大きすぎて webcomponents の末端にするのは難しい。 やりたいこと <script la

                                  Svelte + TypeScript のベストプラクティスを考える
                                • webcontainer とは

                                  stackblitz が提唱して実装している node.js が動くブラウザ環境。container といってるが、 Docker 等とは関係ない。 stackblitz/webcontainer-core このコンテナはブラウザ内で node.js (らしきもの)が動くことがターゲットで、現在デモとして next.js をビルドしてプレビューできている。これによって node.js + webpack + next.js cli が動いていることがわかる。 デモはここで試せる。 まだ OSS ではないので、この記事の大部分は想像によって書かれている。 webcontainer 概要 (自分の理解なので話半分に) ブラウザサンドボックスでも electron なしでも動かせるようになってきた。しかし現在 node.js を動かすには色々と欠けている部分があるので、それらを総称して webc

                                    webcontainer とは
                                  • 「理論上は最強」の Qwik/QwikCity を、フロントエンドの共通基盤にできないか

                                    Qwik をマイクロフロントエンド基盤として使えないか検討していて思いついた色々。副産物で色々作った。 tl;dr Qwik は理論上は最強。だが難しい qwik-react を使えば選択的に Qwik/React を切り替えられるので、 Astro と同じメタフレームワークとして使えそう React 以外もその気になれば対応できるはず => qwik-svelte と qwik-vue を実装した 最終的な問題は Qwik が流行るかどうか Qwik/QwikCity とは何か Qwik は SSR First なUIライブラリで、 .tsx の React 方言からコンポーネントを生成する。 import { component$, useSignal } from '@builder.io/qwik'; export default component$(() => { return

                                      「理論上は最強」の Qwik/QwikCity を、フロントエンドの共通基盤にできないか
                                    • Next.js から Prisma ORM を利用する

                                      Next.js に Prisma ORM を導入する方法について解説します。 Next.js プロジェクトの雛形を作成 $ mkdir hello-next-app && cd hello-next-app $ npm init -y $ npm install next react react-dom --save $ npm install typescript @types/node @types/react --save-dev $ code src/index.tsx

                                        Next.js から Prisma ORM を利用する
                                      • CSSを持たない Headless な UI ライブラリと ChatGPT によるマークアップ生成を試してみる

                                        いまさら気づいたけど Headless 系のUIライブラリが一番 AI と相性いいのではないか。 ロジックはプログラマで書けて自由度高いし、コンポーネントのネスト構造から意図を読み取れるだろうし、class 名は自由に書けるから意図を表明しやすい。 それをプロンプトとして ChatGPT or Codex にそのまま投げて書かせる、ができる。 というわけで vite + react + radix-ui + vanilla-extract で実験してみた。 プロンプト あなたは凄腕のマークアップエンジニアです。 radix-ui は Headless UI ライブラリで、UIとしてのセマンティクスのみを持っています。 次のコードは React + radix-ui + vanilla-extract で書かれた React コンポーネントです。 // Popover.tsx import

                                          CSSを持たない Headless な UI ライブラリと ChatGPT によるマークアップ生成を試してみる
                                        • select-frontend-tech.md

                                          You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                            select-frontend-tech.md
                                          • コロナ禍の真っ只中、夫のダイエットに協力した話 - いくらどん

                                            ※この記事は専門家の意見ではなく、個人の意見や経験、感想に基づいて書いています。 きっかけ 夫がウイルス性肝炎になり、その際の検査で脂肪肝になっていることが判明。 (数ヶ月後ツイッターで他人から指摘されましたが、実は2016くらい?にすでに脂肪肝になっていた証拠ツイートがあるらしい。知らなかった…。ありがとう、夫のファン。) 判明当時、まだ入籍前だったがこれはまずいぞということで夫の同意を取り健康管理をすることに。 夫を見ていると、過剰な糖質制限をしていたのは知っていたので(まあそうだろうなあ)という感想。当時も、ビーフジャーキーを超大量に食う。ナッツを大量に食う。私が出社等で家にいないときはポテチ食ってる(掃除機かけてるとポテチの破片が散らばっている)。 そんな感じなので、そもそも「ダイエットさせる」というよりは「そこそこ健康な状態にさせる」ことが目的。 自分のダイエット経験 (精神疾患

                                              コロナ禍の真っ只中、夫のダイエットに協力した話 - いくらどん
                                            • React Server Component の Isomorphism について解説する

                                              Next.js + React Server Component のリファレンス実装が出たので、手元で動かしながら理解したメモ。 vercel/next-server-components: Experimental demo of React Server Components with Next.js. Deployed serverlessly on Vercel. これを書いてるモチベーションとして、Twitter を見る限り React Server Component のことを 「ただのサーバーサイドへの先祖返り」とか「SSR 結果を dangerouslySetInnerHtml してるだけでは?」みたいな反応があったので、そのへんの誤解を解きたい。 Introducing Zero-Bundle-Size React Server Components – React Bl

                                                React Server Component の Isomorphism について解説する
                                              • Gatsby + TypeScript で技術ブログを書くための知見

                                                Blog を作りました!!!!! 会社を辞めて 5 ヶ月経とうとしており、ついに堕落しきった生活による危機感が生まれはじめました。 その危機感が結実したものがこの Blog です。 で、Blog を作ってみたものの書く内容が特にないので、まずはこのブログをどうやって作ったかについて書きます。 「こういう記法にちゃんと対応できてる?」を試す目的でもあります。 技術スタック 根幹になっているものは、 TypeScript Gatsby です。 元々は amdx + NextJS, もしくは完全自作 SSG を考えていたのですが、 ブログは完璧を目指しているといつまでも完成しない ということは知っているので、自分にとって自信があるツールとして Gatsby を選びました。 しかし、ただ使うだけなのはチャレンジ性がなかったので、TypeScript を使ってみることにしました。 昔の Gatsby

                                                  Gatsby + TypeScript で技術ブログを書くための知見
                                                • next.js + vercel + firebase authentication で JWT の検証を行う + Graphql

                                                  今個人で作ってるアプリの 認証 + Graphql の部分を抜き出して GitHub に公開した。 mizchi/next-boilerplate-20200727 next.js + vercel + firebase は (パーツを良く選べば) 最高 next.js はルーティングを持つページを作るには最高で、サーバー、静的サイト、JAM スタック、AMP と必要に応じて選択できる。React ベースならこれ一択。 認証サーバーの実装は毎度疲れるし、Firebase Athunetication はこの点においては OAuth Secret を置くだけ + Custom Provider も作れるので、最高。 それと比べて firestore は、ちょっと前に firestore べったりでアプリを試作したことがあったのだが、型がないためにかなり扱いづらく、また読み書きの速度が遅くパフ

                                                    next.js + vercel + firebase authentication で JWT の検証を行う + Graphql
                                                  • RailsアプリをHerokuから移行するならどれがいいのか比較する | うなすけとあれこれ

                                                    Herokuの移行先を考える 今運用しているアプリ達をすぐにHeroku以外に移すということはしないまでも、競合となるプロダクトの調査をしておくことは(特に後発のものについては)機能面で実はこんなに便利なものがあったのか、と気づくことにもなったりするので、やっておいて損はないかと思いました。 比較対象について 比較する対象としては、インターネットで最近見かけるPaaSを選定しました。同様のことができるIaaSのコンポーネントとして、AWS FargateやGoogle Cloud Runがありますが、そのようなIaaSの一部として提供されるものについては今回は比較対象とはしません。 今回の比較対象は以下3つです。 Render https://render.com Railway https://railway.app Fly.io https://fly.io deployするRails

                                                      RailsアプリをHerokuから移行するならどれがいいのか比較する | うなすけとあれこれ
                                                    • 「家で読む」ために。面白いエントリーを100集めました - ジゴワットレポート

                                                      とにかく Stay Home で Social Distance な昨今。急速に高まる「家で楽しむコンテンツ」の需要に(微力ながら)応えるため、独断と偏見による「面白いエントリー」を集めてみました。 その数、100。 ご多分に漏れずネットサーフィンが趣味なもので、はてなブックマークを重宝しています。なので、自分でブックマークしたエントリーを過去5年分ほどさかのぼり、「ウッヒョー!そうそう、これ読み応えあった!」「くっだらねー!サイコ~!」「あぁ~これは多くの人に読んで欲しい……」等々の、心震えた逸品をまとめました。もちろん、はてブで話題になったエントリーも多く入っていますが、私が個人的に感動した個人のブログや、資料的価値を感じたものまで、とにかく盛り沢山です。 「面白い」には色んな意味があって、時に「Funny」で、時に「Interesting」。ページを開いて鼻で笑って終わるものから、ち

                                                        「家で読む」ために。面白いエントリーを100集めました - ジゴワットレポート
                                                      • React Context を用いた簡易 Store

                                                        課題 redux を引っ張り出すと大仰になる。Context 下に共有ステートを持ってそこに setState できるだけでよい。 なので、次の 2 つを用意する 現在の state を参照する const appState = useAppState() 現在の state を更新する関数を返す const setAppState = useSetAppState() React.useState() と違って分割している理由は、主にパフォーマンス上の理由 大域な参照なので、可能な限りステートを参照したくない setState() の API は (prevState: State) => State も取れるので、状態更新用途に限ってはそもそも useAppState() せずに済むことが多い でも毎回書いてるけどボイラープレート感強い上に忘れるのでここにメモする 毎回書いてるボイラー

                                                          React Context を用いた簡易 Store
                                                        • Cloudflare Workers を活かしきるスタックを考えた(remix+d1 on pages-functions) + 残タスク

                                                          Cloudflare Workers を活かしきるスタックを考えた(remix+d1 on pages-functions) + 残タスク このスクラップ で試行錯誤していたまとめ。 最終形はここにアップロードした。 docs の下に、このリポジトリを生成した手順、セットアップ方法、リリース方法を書いてある。 (remix-validated-form や vitest のテストの追加でもうちょっといじるとは思う) なぜ cloudflare-workers + d1 のポテンシャルは最強で、近い未来、開発者|個人開発者の銀の弾丸になると思っているのだが、それを活かす開発スタックが知られていない(要出典)。この記事では GW の間に自分で周辺ライブラリを使い倒しながら選定していった。 2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを

                                                            Cloudflare Workers を活かしきるスタックを考えた(remix+d1 on pages-functions) + 残タスク
                                                          • FF14を新生から暁月まで45日で駆け抜けた感想

                                                            You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                              FF14を新生から暁月まで45日で駆け抜けた感想
                                                            • Zig 言語のファーストインプレッション

                                                              Bun を読むにあたって、まずZigを抑える必要があると思ったので数時間学習してみた。チュートリアルを一通りやったのと、ちょっと手を動かした程度で、正直エアプの域は出てない。 自分の動機として wasm を吐くのに使う言語をずっと探していて、Rust も悪くないが正直学習コスト高すぎでしんどく、Zig がそれに足るか調査していたという感じ。 この記事を書くにあたっての細かい作業はこちら https://zenn.dev/mizchi/scraps/287b4414da2b29 Zig 言語自体のスタンス まず Zig 言語自体がなぜ D や Rust ではないかはこの記事がわかりやすい https://ziglang.org/learn/why_zig_rust_d_cpp/ 以下 Deepl で訳してちょっと修正したもの nostd 指向 標準ライブラリなしでもファーストクラスでサポート

                                                                Zig 言語のファーストインプレッション
                                                              • Git と GitHub の次を妄想する

                                                                GitHub みたいなサービスを今一から作るならどの言語・フレームワークを使うか GitHub の次は何かを考えてみるのは、現実に実現困難なのを忘れれば、なかなかに楽しいことではあります。ここではその妄想をやっていきましょう。 GitHub の抱える課題を分割すると、Git の問題と、 GitHub の提供する機能の問題に分けられると思います。自分は、Git をベースとして GitHub に勝つのは現代ではなかなか難しいと考えています。MS による買収と実際に注ぎ込まれてる資本を考えると、よほど斬新な切り口でないと、 同じ Git を使っても優位性は出せません。 なので、 GitHub に本質的に勝つには、その基幹となる VCS から考え直すとよいのではないか、と考えています。幸いなことに(?)、Git はその優秀さは認められていますが、学習の困難さや特定のユースケースで機能しないことが知

                                                                  Git と GitHub の次を妄想する
                                                                • プログラミング学習の通過儀礼

                                                                  プログラミング学習とはそもそも何なのか プログラミング初学者やITに関わる人が最初に知るべきこととして、プログラミングとは「あなたが問題を解決するのに用いたい手段を、あなたが思っているようにコンピュータに入力すること」ではない。 実際には、プログラミング学習はコンピュータに可能な(非常に限定された)処理セットを学ぶことであり、その応用の先に当初のゴールが含まれるかは、プログラミングを学んでその特性を学ばないと、判断すらできない。 例えば、手段 A によってゴール X を達成したいとしよう。非プログラマ/プログラミング初学者の発想は、よほど目の付け所がいいのではない限り、次のいずれかに分類される。 A には同じゴール X を解決する簡易な代替手段 B があり筋が悪い。 A で実現するほどの価値がない A は現状の人類の既存のソフトウェアの応用では実現できない。あるいは非常に困難。無理に実現し

                                                                    プログラミング学習の通過儀礼
                                                                  • 既存プロダクトに最小構成でTypeScriptを導入する - RAKSUL TechBlog

                                                                    こんにちは。 印刷のラクスルでフロントエンドを担当している菅野です。 現在、稼動中のとあるプロダクトへのTypeScript導入を進めています。今回は、既存プロダクトへの影響を最小限に留めつつTypeScriptを導入する手順をご紹介します。 TypeScriptとは TypeScript - JavaScript that scales. TypeScriptは、Microsoftが開発したオープンソースのプログラミング言語です。 詳細な説明は省きますが、以下のような特徴があります。 JavaScriptの厳密なスーパーセット(≒上位互換) 省略可能な型システム クラスベースのオブジェクト指向 TypeScript導入にあたって 今回TypeScriptを導入することで、以下のようなメリットがあります。 型システムの恩恵が得られる エディタの入力補完を受けられる コード=ドキュメントとい

                                                                      既存プロダクトに最小構成でTypeScriptを導入する - RAKSUL TechBlog
                                                                    • Chrome(Canary) の Native File System API で ローカルファイルの読み書きをする - mizchi's blog

                                                                      ブラウザ上でローカルファイルの読み書きができる Native File System API が ChromeCanary で実装された。 前々から欲しかった機能なので、自分が作ってる markdown preview ツールに実装してみた。 Intent to ship https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/noan0cgEBGQ/t8DuK8_hDwAJ 仕様 http://wicg.github.io/native-file-system/ 動かすとこんな感じ https://mdbuf.netlify.com/ で Meta+O/Meta+S のキーバインドを振ってる。 有効化 https://www.google.com/intl/ja/chrome/canary/ をダウンロード chrom

                                                                        Chrome(Canary) の Native File System API で ローカルファイルの読み書きをする - mizchi's blog
                                                                      • Hello, Deno v1.0.0

                                                                        Deno 1.0.0 がリリースされて、ちょっと遊んでみたので、その感想。 圧倒的ゼロインストール感 自分は mac なので brew install deno しました。deno コマンドが入ります。セットアップはこれで終わり。 GitHub の trending に上がっていた https://github.com/oakserver/oak という web server を試してみます。 // server.ts import { Application } from "https://deno.land/x/oak/mod.ts"; const app = new Application(); app.use((ctx) => { ctx.response.body = "Hello World!"; }); await app.listen({ port: 8000 }); この

                                                                          Hello, Deno v1.0.0
                                                                        • 自分がプログラミング力の成長を実感できるようになった瞬間について

                                                                          私はプログラミングを 3 年近くやってみて、「ただ知らなかっただけで損した」という悔しい経験をたくさんしました。 そこで自分にとって「これを知っているだけでエンジニアとしてステップアップできた」というものをまとめてみようと思います。 ちなみにステップアップする前の私はこのようなとても凄いコードを書いていました。 ご査収ください。 プログラミングを始めて最初に作った成果物です。 https://gist.github.com/sadnessOjisan/6f1a1956d4848e3c17f0c0c5af28cfb8 (//varを付けたらダメだよ(ローカル変数になっちゃう。関数内だからローカル変数使うと外部からアクセスできない) というコメントがすごい・・・) はじめに 書こうと思ったきっかけ 自分は大学生の時にプログラミングに触れたことがあるものの情報系を出ておらず、エンジニアになったの

                                                                            自分がプログラミング力の成長を実感できるようになった瞬間について
                                                                          • 離婚します - mizchi's blog

                                                                            最初に言っておくとmizchi と syake の 離婚はお互い嫌いになったという理由ではなく、単に結婚に求めるものが違っていて、その齟齬が顕著になった、ということに尽きます。 mizchi と syake は離婚しても友人であり、一緒にイベントなどもやる予定があります。これからも仲がいい友人であり続けるために適切な距離が必要になり、それには婚姻契約や同居がお互いにとって邪魔になったよね、という同意に至りました。 この2年間は本当に楽しかったです。結婚前にあった課題感、「エンジニアとして似たようなサイクルを繰り返すだけの予測可能な人生を打破したい」という当初の目的も達成できました。自分と違う人間と生活することで、様々な局所最適に陥っているのを自覚できるようになりました。これについて、syake には本当に感謝しています。 これ以上詳しいことを知りたい人は、Twitter で「ワインと鍋」に

                                                                              離婚します - mizchi's blog
                                                                            • プログラミングで辛かったこと。よかったこと。|Seiji Takahashi@ベースマキナ

                                                                              この流れです。 前提基本的に自分はGoのサーバーサイドが主戦場で、カンファレンスにはよく顔を出します。最近はOSSを公開すればいい感じにGithub Trendsの上の方にきて目立つような、芸人っぽいムーブができるようになりました。 ですが、直近プライベートではGo以外にTypeScript(Next.js) でGraphQLのクライアント書いたり、仕事だと前はSwiftやらC++やらPerlやら色々使っていたので、他の方と比べると広く浅い経歴です。 また、大学に入ってから学習を始めましたし、当時はドットインストールが出始めたくらいで、基本的には書籍で勉強していました。大学では授業でFORTRANの授業を取りました。内容は意味わからなかったので同級生に寄生してました。 Progateとかプログラミングスクールとかには頼ってませんでした。無かったので...。なので、「幼少期からBASICを触

                                                                                プログラミングで辛かったこと。よかったこと。|Seiji Takahashi@ベースマキナ
                                                                              • GitHub Actionsのワークフローを利用してクロスブラウザのE2Eテストを自動化する - Money Forward Developers Blog

                                                                                こんにちは。 『マネーフォワード クラウド経費』のフロントエンドエンジニアをしている木村(@kimromi)です。 Ruby on Railsを利用してサービス開発を進めているプロダクトのフロントエンドの環境を整えていき、UIの改善やフロントエンド側の開発効率アップなどにつなげていくような動きを現在やっています。 なぜクロスブラウザのE2Eテストが必要になったか ある日、IE11のみでJavaScriptエラーが起こり動作しないとの連絡が入り、慌てて対象のプルリクエストをリバートしたということが起こりました。 原因としてはライブラリの追加によるものでした。 現在フロントエンドの改修を行っていく中で、ライブラリの追加やビルド方式の変更などドラスティックな変更をすることが多くなってきています。 そのたびにMicrosoftからダウンロードできるVM環境を立ち上げ手元で確認するのは手間がかかり確

                                                                                  GitHub Actionsのワークフローを利用してクロスブラウザのE2Eテストを自動化する - Money Forward Developers Blog
                                                                                • 人類は(いつ?/そもそも?)ビジュアルプログラミングに至るのか。またはプログラミング的思考とはなんなのか - mizchi's blog

                                                                                  西村賢さんのこの記事について coralcap.co 68件のコメント https://t.co/jGBUcpTCoK “プレーンテキスト Markdown 時代の終焉 - portal shit!” https://t.co/1Q831CDuXY— 限界シェアハウスみたいなTL (@mizchi) 2019年11月18日 ↑ の記事や、あとは最近の slack の wysiwyg 化について色々思うところあった。 wysiwyg は人類の技術の進歩なのかコンピュータへの適応の失敗なのかは議論の余地がある— 限界シェアハウスみたいなTL (@mizchi) 2019年11月19日 編集してるものと、出力されるものが違う、という発想、エンジニアの発想であるのは間違いなく、markdown を使うのはプログラミング的な思考や訓練が前提にあるのはそうで、人間を訓練するか、内部状態が汚れるのを許容

                                                                                    人類は(いつ?/そもそも?)ビジュアルプログラミングに至るのか。またはプログラミング的思考とはなんなのか - mizchi's blog