はてなブックマーク

iOS safariの暴虐 iOS safariでは、スクロールできる要素に対してスクロールバーを表示しないという正気を疑う挙動をします。 現代は端末幅にあわせてコンテンツの幅を柔軟に調整するのが一般的需要ですから、画面幅によっては運悪くちょうどキリのいいところで文章が切れてしまうことは十分にありえます。そんな場合、ユーザーはその要素がスクロール可能だとはまるで気づきません。 もちろん、iOSを使っている人間はそういう不自由さを受け入れる覚悟があるからApple製品を使っているのです。愛の前では使いにくいことなんて何の障害にもなりません。 しかしサービス運営者としては困りものです。Appleなんか好きでもなんでもなくても、そういう暴虐の限りを尽くした挙動にも対応できなければ「使いにくい」っつって文句言われたり、コンバージョン率が落ちたり、ビジネス的な損失につながるのです。無視したくても無視

ウェブアプリケーション開発における、現代的なCSSの基礎技術についてまとめました。 ちまたには「CSSとは何か」を学ぶ教材はたくさんあっても、「CSSをどうやってうまく使うか」についてはあまり詳しく触れられません。 仕様をたくさん記憶したところで、いつになっても開発力はあがらないのです。 本記事は「CSSをうまく使う技術」に焦点をあてて、実際に現代的なウェブアプリケーションに求められるレベルのCSSを書くための知識を紹介します。 特に プログラミング経験はあるもののウェブフロントエンドの経験が浅い方 初級レベルのCSSはある程度理解したものの、次にどうしたらいいかわからない方 にお勧めです。 プロローグ CSSの書き方は一通りではありません。 好きな書き方を自由に選ぶことができます。 これは一見すると良いことですが、裏を返すと最適ではない書き方がたくさんあるということです。 この場において

これまで未婚の父として娘のヤギさくらちゃんを育ててきましたが、2日後に命を奪う決断をしました。 (12/3(火) 14:22 さくらちゃんは旅立ちました) ある日、突然目が見えなくなり、次の日には立つことができなくなっていました。 自由にならない体にもどかしさを感じ、目が見えない恐怖にのたうち回りながら 体をぶつけ、顔をぶつけ、歯も折れてぼろぼろになってしまいました。 信頼できる獣医さんの愛にあふれた治療の結果、危篤状態は免れたものの 根本的な回復にはいたらず、2週間の介護を経て安楽死の判断をしました。 1月生まれで間もなく3歳でしたが、その日を迎えることはありません。 人間で言えば18歳くらいでしょうか。 人間の都合で親や兄弟と引き離し、最後は自分の意志とは関係ない第三者によって命を奪われる。 死後は一面のきれいなお花畑で、仲間たちとお花を片っ端からむしゃむしゃ根こそぎ貪り食って過ごして

CSSは、勉強してないのをごまかすためにイキって強がる人の風評被害を受けやすく、実際よりも低く評価されてしまうことがよくあります。 でも現代のCSSは意外に良いものですし、依然として残る課題に対しても「名前空間がないからCSSマジつかえねぇわ〜」と知ったかぶりして書かない理由を探すのではなく、やはり生産的に解決したいものです。 そこで、この記事ではCSS modulesを使って お手軽に CSSに名前空間を擬似的に導入します。 また、ParcelでCSS modulesを使う時に遭遇するバグの回避方法もあわせてお見せします。 CSSに名前空間がないことで起きる問題 CSSには名前空間がないため、たとえばこれからご紹介する例のように複数のCSSファイルを読み込んだ際に意図せぬ見た目になってしまうことがあります。 まず、以下の yagi.css だけを読み込んでみましょう。 .yagi { w

GUIのアプリケーションにおいて、ユーザーが入力した内容を検証する「フォームバリデーション」は必須の技術です。 しかし、静的型付けの恩恵を受けるために Flow, TypeScript, Elm, PureScript などをつかってフロントエンドコードを書くようになると、実はフォームバリデーションだけでは足りなくなってきます。1 この記事ではフォームバリデーションを包括した新しい概念である フォームデコーディング を紹介し、Elmでフォームデコーディングを実践するために開発した elm-form-decoder を使った実例をお見せします。 軽く調べた限りではフォームの入力検証について同等の概念を実現するライブラリなどは見当たりませんでしたが、もし似たライブラリなどをご存じの方がいらっしゃればご指摘いただけると幸いです。2 サンプルアプリ まずは現実にありそうな簡単なアプリケーションを題

URLをあらわす文字列であるとか、0以上であることが要求される整数であるとか、値が何らかの制約を満たすことを要求される場面は多くあります。 たとえば、男女2頭のヤギさんの角の本数を引数にとって、その2頭のヤギさんが愛し合って交尾して子どもを作っても問題ないかを判断する関数を定義します。 それぞれの角の数を引数にとって Bool型を返す自然な設計ですね？ でも、ちょっとまってください！ 有角のヤギさんは2本しか角を持っていません。 そのため、ヤギさんのとりうる角の数は以下のいずれかしかありえないはずです。 0本: 生まれつき無角のヤギさんか、有角の仔ヤギちゃんの角芽を焼きごてで焼いた（断末魔のような悲鳴がする） 1本: 有角の仔ヤギちゃんの角芽を焼いたけど不十分で1つだけ残った（断末魔の悲鳴が無駄になった😱） 2本: 生まれつき有角 3本以上: 染色体に異常があるので、ここではヤギとは見な

Haskell を用いたアプリケーション開発は 「新しく作るのには時間がかかってしまうが、その代わり強い静的型のおかげで保守性が高い」 と言われることがよくあります。 もちろん「いや、新しく作る際にもむしろ型のおかげですばやく作れる」などの反論もありますが、こういったトレードオフがあることもまた事実です。 さらに、Haskellの闇の力に飲まれてしまった方が書く厨ニ病コードは、本人すらも1週間後には意味がわからなくなって保守性すら低くなる怖さも秘めています。 今回ご紹介する Tonatona は、Haskellを用いたアプリケーション開発にありがちなこういった問題を解決して、今までの常識を覆す「統合的アプリケーションフレームワーク」です。 公式リポジトリ 最新の内容はTonatonaのリポジトリにあります。 トナカイのコスプレをしたさくらちゃんが目印です。 どんな人のためのフレームワークか

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 高品質なウェブフロントエンドを作るための言語 Elm の有用性が徐々に広まり、今年も採用事例が増えました。 利用者数が増えることは良いことではありますが、一方で悪気なく誤解を招く情報が生まれてしまう機会も増えてきます。 そこで、本記事はこれからElmをはじめる人やはじめて間もない人1が遠回りしないで Elm をモノにできるように、Elm を学ぶ上で落とし穴となる注意事項とその回避方法をまとめます。 なお、本記事で対象にするのは「実際に Elm を使って実用的なアプリケーションを作りたい」と考えている方です。 Elm をマウンティングのた

Elm0.19になって、Elm0.18時代の elm-tools/parser も elm/parserとして新しく生まれ変わりました。 基本文法は Elm0.18時代 とほぼ同じなので、去年@jinjorさんが書いた Elm0.18の elm-tools/parser に関する記事の「基本文法」までを読めば理解できますが、Elm0.19から新たに加わった変更がいくつかあります。 そんな変更の1つ "backtrackable" は、elm/parser からリンクが貼られているドキュメントに説明がありますが、あまり親切とは言えません。 そこでこの記事ではより詳しく「そもそも backtrackable とはなにか」「どうやったらうまく使えるか」などをまとめました。 backtrackable とは ざっくり説明すると「ひとかたまりのParse処理において、途中でParse処理が失敗した際

HTML側がこの JSON オブジェクトを使って適切なクラス名を各要素に付与するようにすることで、無事に CSS で定義したスタイルがその要素に適用されます。 このようなクラス名の衝突をなくす工夫によって、アトミックデザインなどに使える再利用可能な CSS の記述が可能になります。 関連手法との比較 「CSS modules を使いたいから Elm で CSS modules を使えるようにした」みたいなのは無能な人がやることです。 いったん落ち着いて「本当に Elm で CSS modules を使う新しい手法を考える必要があるのか」「他にクラス名の衝突を回避する方法はないのか」について考えましょう。 せっかちな方は elm-css-modules-helper の使い方 まで読み飛ばしてください。 CSS in JS (elm-css) との比較 CSS modules とよく比較され

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは、UXデザイナーではない人がUXデザインを効率よく身につけるための方法論です。 私自身も本職はUXデザイナーではなく、ふだんはヤギと遊んだり新しい会社組織の実験をしたりプログラムを書いたりしています。 しかし、ヤギの飼育や経理、組織運営、マネジメント、営業、プログラミングのどれも、広い視野で見ればユーザー（＝ヤギ、組織の構成員、マネジメントの対象、取引相手、他のプログラマ）の体験を改善する仕事です。 そのためUXデザイナーではありませんが、これらの「UXハッカー」と呼ぶべき多くの分野から得られた知見を用いて、UXデザイナーではない

型って「どういうことをしてほしいか」っていう 要件 の役割を持ってて、 一方で実装って「どうやってその要件を実現するか」っていう 具体的な手順 の役割を持ってますよね。 ところで仕事ができる人って、「こういうことやりたいな〜って思ってるんだけど〜」って伝えると、 「あ、それなら具体的にこういうやり方をすると良さそうですね〜」って自分で考えて提案して実行してくれてめちゃくちゃ助かるじゃないですか。 そしたら、プログラムの世界でも同じで、要件 (型) だけ書いたら 具体的な手順 (実装) を自動で導出してくれる未来が来たら嬉しい感じがしませんか？ ざんね〜ん！ 未来ではなくそれは現代のお話でした〜！ 1 type MyApi = "books" :> Get '[JSON] [Book] -- GET /books :<|> "books" :> ReqBody Book :> Post '[

Elm でどのように見た目をあつかうかについて僕がいま考えていることをまとめました。 結論として「BootStrap みたいな方針でCSSを書いて使えばいいよ」という単純な話を、 だらだら歴史的経緯とかどうでもいい話をしながら書きました。 従来の主張 まず、「見た目をあらわすクラス名を使うべきではない」と言われてきた背景をおさらいしたいと思います。 ここで言う「見た目をあらわすクラス名」とは、BootStrapのような方式のCSSフレームワークで採用している HTMLのクラス名に col-sm-8 や pull-right のような見た目に関わる名前のクラスを入れる方針のことを意図しています。 従来は HTML/JS/CSS の役割を次のように分け HTMLがページの構造のみを記述し JSが挙動のみをあつかい CSSが見た目をどう見せるかを全て制御する こうすることで、見た目の変更をしたい

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 高品質なWebフロントエンド開発を可能にするためのプログラミング言語Elm。その長所を上げればキリがありません。 強い型制約によって実行時エラーをほぼゼロにできること リリースごとに言語機能が減るというどこまでも考えつくされたシンプルな設計 それでいて実用的なアプリケーション開発にとことん貪欲な機能たち まともなパッケージマネージャー テストしやすさ ...... 一方で、そういった強力な武器たちの切れ味を保つために他の言語とは異なる事情を抱えています。 本記事では、その特有な性質がゆえに誤解されてしまうことも多い Elm と

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 僕の本業は酪農で、ヤギのさくらちゃんをお世話するのが仕事ですが、それだけでは食っていけないのが世の中の悲しさなので、副業でフリーランスのITコンサル(兼プログラマ)や株式会社UZUZっていう会社のひきこもり系最高技術責任者としてHaskellやElmを業務で使っています。 あと、個人的な趣味で株式会社ARoWっていう社員数2名のちっちゃいWeb系の会社を実験的に経営していて、そこでもメインにHaskellを使っています。 Haskellを実際に小規模な会社やフリーランスで使っている人って、実は世の中にほとんどいないみたいです。

フリーランスプログラマであれば、複式簿記で青色申告するのは自力でも容易にできます。 もちろん、年度ごとに法改正などに対応するのは面倒なので、複式簿記の仕訳帳記入を日頃からプログラマティックに記述しておき、 年度末にそのプログラムを元にCSVを吐き出し、MFクラウド（無料プラン）とかにインポートするのが、僕が見つけたもっともコスパがいいやり方です。 この記事では、僕がどんな感じで毎年記帳と確定申告をしているかをご紹介します。 ただし、確定申告書の内容については保証しないので、ご自身で税務署に確認するなりして自己責任でマネしてください。 対象者 個人事業主として活動しているプログラマ。 ここで紹介する簡単なHaskellコードにじんましんが出ない方。 仕訳CSVの作成 最新のhaskell-bookkeeping-jp-sampleを参考にしてCSVファイルを作成します。 Haskellは言語

はじめに Elmという名前を聞いたことがありますか？ Reduxを使ったことがある方は、「ああ、Reduxのもとになった言語ね！」と思ったかもしれません。 世間では、「Elmは設計思想としてはいいけど、Haskellの知識がないとわからないし難しい」みたいな嘘にだまされて、「JSの知識だけで使えるし、簡単なReduxの方を使ってみよう！」と思う方も少なくないようです。 しかし、Elmは難しくありません。 Elmは、初心者でも簡単に使える言語であり、かつ実業務で採用してもJSで書くよりも保守性や拡張性が高いコードを書くことができます。 実際に、最近のバージョン0.17, 0.18, 0.19では、機能が追加されるどころか、「この機能は紛らわしい」「この機能は別の機能で代替できる」という理由で削られ、どんどんシンプルになっていっています。 (Elmの興味深い思想についてもっと知りたい方はElm

問題提起 近年、フロントエンドを Elm1 や React.js などで実現することが多くなり、Webサーバに求められる役割は、JSON形式のAPIを提供するだけでよい例も増えてきました。 しかし、規模によってはHTMLにサーバサイドで変数を埋め込んでそのまま表示したい案件も多く存在します。 JSON形式で良ければaesonなどの恩恵にあずかれば良いのですが、Haskellで書かれたWebサーバで、バックエンド側の変数を埋め込んだHTMLレスポンスを返すにはどうしたらよいでしょうか？ Yesodの解決策と課題 HaskellのWebフレームワークとして歴史のあるYesodでは、Shakespeareを推奨しています。 Shakespeareは、Haskellっぽいインデントベースの文法を強制されるというデメリットがありますが、Template Haskellによってコンパイル時にテンプレー

(筆者は今では積極的にはこの手法を使っていません。詳しくは追記をご覧ください。) elm-cssライブラリのCSS生成機能とelm-css-webpack-loaderを用いることで、CSS in Elm のさまざまな恩恵にあずかれます。 はじめに なぜ CSS in Elm が必要か CSS in JS という言葉が、React界隈で使われるようになっていくらか経ちました。 CSS in JS は、本来 CSS で記述するスタイルを JavaScript で書いてしまうことで、名前空間やネスト構造が使えない不便なCSSから解放されることを目的にしています。 Elm で CSS in JS (Elm) を採用することで、従来のCSSによるスタイルにおける以下の問題を解決できます。 a. スタイルの記述が Elm コンポーネントとは別のファイルになって、配布しづらい b. CSS に名前空間

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? なぜこれを書くのか 私がQiitaに投稿した記事を見た方から、メールが届きました。 プログラミング言語のHaskellを勉強し始めたものの、難しくてやめようかと考えているそうです。 その気持ちも非常によく分かります。 すごいH本が出版されてから年月も経ち、それなりに勉強しやすくなったとはいえ、お世辞にもHaskellを学ぶ環境が整っているとは言えません。 私はHaskellで製品開発をする会社を保守運用していたことがあり、また自分自身もHaskellでプログラムを書いています。 また、Haskellを普及させるべく、「こわくないHask

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

こわくないHaskell入門(初級その2) 手続き型に慣れた人にもやさしい、こわくないHaskell入門記事の第2弾です。 初級のつぎは中級だと思った？ 残念。 まえがき 前回のやつのViewsが1000を超えた記念に続編を書いてみます。 前回は「Haskellって関数型（この言葉を見るだけで、うっ頭が...）とか呼ばれるけど、ふつうに手続き型でこわくないよ」を示しました。 今回はHaskellの型についてです。1 Haskellは強い静的な型付言語と呼ばれていてこわそうですが、実際にはこわくないです。 むしろ僕みたいにプログラム書くのがうまくない人がよろしくやれるようになります。 型を使えるようになって、いままで以上にコンパイラちゃんと仲良くおはなししましょう。 対象者 なんかもっと生産性の上がる言語を習得したい人 なんかHaskell入門しようとして挫折しかけた人 なんかマサカリ投げた

手続き型に慣れた人にもやさしい、こわくないHaskell入門記事です。 「なぜHaskellを学ぶと良いか」も参考にしていただければ幸いです。 まえがき Haskellと聞いて、何を思い浮かべますか？ モナド 関数型 遅延評価 第4世代Intel Coreプロセッサ アライグマ いろいろ思い浮かべるかもしれませんが、Haskellがすばらしいのはモナドを利用しているからでも、遅延評価型の純粋関数型言語だからでもありません。 いろいろな「Haskellらしさ」が集まって、その結果Haskellにしかないすばらしい魅力を提供してくれます。 それは、決していままでのパラダイムと対立するものではなく、 手続き型 構造化プログラミング オブジェクト指向 のようなこれまでの便利な道具をうまく抽象化しながら統合して作り上げられたものです。 PHP javascript C++ Java などにあなたが費

追記 その後restの開発が微妙な感じなので、servantとかspock使うのをオススメします。 servantはtype level foobarをたくさん使っているので、弊社のブログ記事を参照してもらえるといいかもしれないです。 はじめに Haskell界隈は素数クラスタの人とかが圏論を絡めたこわい話をするのが日常です。 まじこわい。 私にはそんなお話できませんが、日頃Haskellを使ってフリーランスの魔法少女（おっさん）をしている経験を生かして、何か実務ですぐに使えそうなお話をしようと思ってAdvent Calendarに登録しました。 今回は、Haskellの rest という（その名の通り）RESTフレームワークをご紹介します。 googlabilityのとても低い名前なので、正しく検索できているかはわかりませんが、 今日現在、このフレームワークについて触れている日本語の文献