「マークアップ」を含む日記 RSS

はてなキーワード: マークアップとは

2017-11-11

anond:20171111072810

UI問題としてとらえると、HTMLテキストマークアップ言語であり、主体テキスト

グラフィカルなシステムは扱いづらい。

ここにポイントがある気がする。

もし、Web記述する言語アバターを使ったシステムを構築するものだったら、

サマーウォーズ』に出てくる仮想世界OZを構築してたかもしれない。

IT技術の禍根

今更言ってもしかたないけど、筋が悪い技術が広まって変えられなくていろいろ災難起こしてるのってあるよね。

Cが広まったのとか。

昔はコンパイラ技術が低くて、ああい言語効率よかったけど、すでに90年ごろには最適化技術が発達して「人間テクニックを使って最適かするより素直に書いてコンパイラ最適化させたほうが実行速度が速くなる」とか言われてたし、Macなんか開発言Pascalだったし。

OSやミドルウエアが(せめて)Pascalで書かれてる世界線だったら、いまのソフトウエア脆弱性は大幅に減ってたと思うわ。

あとマークアップ言語HTMLの上で動的型のJavascriptを動かして、フロントエンドプラットホームになってしまってるのとか。

一時期、ネットアクセススマホアプリから行うのが一般的になって、Webは衰退するって観測で、いい方向に向かってたけど、最近アプリ開発までDOMの上にReactとか積み上げてJSでやろうみたいな流れがあるし。

業務アプリなんかもPHPJSの人に、昔のクラサバのほうが開発効率よくてユーザーの使い勝手もよかったって言っても全く理解できないみたいだし、どんどん悪い方向に向かってるな。

2017-10-16

Markdownは使いにくい

Markdownはただのマークアップ言語

HTMLに「画像を挿入」できないのと同じ


で、まあ、Markdownはその出自上「テキストファイルで見たときにそれなりの構造を反映した見た目であること」を重視してる

Markdown文書さらHTMLPDFに変換することをあまり目的としていないのだ

からそもそもグラフィカルな編集サポート機能画面があるならその編集画面内での記述方法Markdownである必要はないというかむしろ害悪なんだよね

画面の内側でXMLなりHTMLなりバイナリで保持してから変換してユーザーリアルタイムに見せればいい

いまのMarkdownは使いどころ間違った使い方をされてることが多いのだ、君は被害者といえる

あとマイクロソフト関係ないぞ!

2017-08-02

Flash終了らしい

Flash製のゲームが存続が危ぶまれてるとか。

文書表示用のマークアップ言語javascriptを組み込んで汎用クライアントにするなんて世界線は狂ってる。

Flashはあつかったことがないんでどの程度のものか知らんけど、どこかにユーザー開発者幸せになれる汎用の規格が普及してる世界線があるんだろうな。

2017-07-19

https://anond.hatelabo.jp/20170719141453

書式と内容の分離って書いてあるじゃん

プレーンテキストマークアップ文章を書くと自動で書式の整ったドキュメントをだしてくれるとか。

そこまでやらなくても、無意味に罫線を多用するフォーマットをやめて、wordスタイル対応できる程度のシンプルな書式にするとか。

まあ、wordスタイル程度でも難しいとか、教育コストが~とか言われちゃうから無理だけど。

2017-05-10

クロスブラウザ対応しろとか言う奴

あなた方のせいで私は今日もおうちに帰れないのです

Webサイトクロスブラウザ対応に携わったことがある者だけがIEに石を投げなさい

http://anond.hatelabo.jp/20170508211030

最初から追記(元増田がどういう環境でどういうソースから電子書籍を作ってるかわからないので、以下は自分のところの話)

新刊電子データなのだから電子書籍にするのも簡単だろとか言う方々はかつてのクロスブラウザ対応のことを考えてもらいたい。

HTML電子データなんだからIE6レイアウトが崩れないようにするなんて簡単だろ」って言ってんのと同じなんだよ。

InDesignEPUB書き出しは現状全く使えず、まともなEPUBを吐いてくれない。

となるとDTPの流し込み用テキストをもとに電子書籍データを作ることになる(そうじゃないところもあると思うが)。

もちろんInDesignから書き出したPDF電子書籍でございと売ればこの手間は省ける。

しかしリフローしない電子書籍文字を拡大するとページの一部しか読めなくなる電子書籍なんて読みたくないでしょ?

NHKテキストなんかはそれやってるけど。

印刷用のPDFデザイン簡素にして、Re:VIEWから直接出力できる程度の装飾しかしないなら話は簡単だ。

同じソースから紙の本向けのPDF電子書籍用のEPUBを同時に生成できる。

その場合でもIllustratorで作ったベクターデータの図を載せる場合PDF向けのEPSデータ(1色)とEPUB向けのPNGデータRGB)が必要だ。

そうなるとPDFEPUBで同じ場所にきちんと同じ図が掲載されているかのチェックが必須となる。

図に修正がかかった場合EPSPNGの両方を間違いなく修正たかチェックが必要

そんななので、紙のデータ電子書籍データをワンソースからサクッと作れる世界が来るまではもうちょっと時間がかかりそうなんだ。

2017-03-19

http://anond.hatelabo.jp/20170319132149

日本のお役所PDF大好きなのは、知っている。霞ヶ関から吐き出される有効資料は、ほぼpdf

一方で、e-statなどでは、ネ申エクセルや方眼エクセルとは、別の方向でcsvデータを公開している。

今、株価が上昇しているIT企業様は、PDFhtmlとを比べるような使い方はしていないのでは?

世界は、IT企業htmlPDFとを比べたらどちらを重用しているのか?

  

googlejava script 推しのJQueryを良く使ってるし、これからは、人工知能時代からxml形式とか、マークアップ言語は、良く出てくると思うよ。

Facebookphpなんでしょう?リア充御用達で、Twitterよりも株価資本も安定している。

これからは、you tubeとかLINEみたいなツールがどんどん出てくるから、先のことは分からないよね。

オープンソースでもGit hubみたいなツールが使われているんだし。。  

そう言えば、perlcgiは、ほぼお亡くなりになりましたね。

2016-11-18

http://anond.hatelabo.jp/20161118215013

第一に、やはりマークアップ記述するコストが非常に大きいように思える。

元々HTMLが書けない素人向けの仕組みだぞ。Wikipediaでもゲーム攻略Wikiでも素人が覚えて編集してるのに技術者が何言ってんだ。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

案件ごとに設計書分けたり、後でマージしたりは、どっちにしろ面倒だと思うけど。

デメリットで思いつくのは、Wikiソフトウェアは廃れる可能性がある、かな。

メンバー設計書をwikiで書きましょうって提案された

私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。

UMLなどの作図にツール使用することはあっても、最終納品物としてはExcel画像として張り付けて提出していた。

もちろんExcel方眼紙については批判もあるのは理解しているが、開発者運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。

 

そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。

設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。

開発者運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwiki知識ほとんどない。

 

彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwiki用語集として活用していたそうだ。

wikiには顧客業務専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。

そういった運用をしているうちに彼はwiki自体設計書とできないか考え、調査したところ実際にwiki設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。

 

私も今調べてみたところwiki設計書を書くという運用をしている会社もあるようだが、メリットデメリットwiki知識があまりない私には判断しかねている。

ぱっと思いつくデメリットとしては、第一に、やはりマークアップ記述するコストが非常に大きいように思える。

記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコスト必要となるように思える。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

 

メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。

第二に、改訂履歴差分が標準で用意されていることもメリットであろう。

第三に、検索が容易であることがあげられる。この点はExcel比較して十分大きなメリットだと思っている。

 

私がぱっと思いつく限りではこんなもんである

はてな諸兄の中にwiki設計書を書いたことがある方がいれば、メリットデメリット、その他運用において気をつけるべきことなどあればご助言願いたい。

 

なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。

そのため自社の標準の設計テンプレート使用する予定だった。もちろんExcelである

 

また、設計作成使用するツールExcelWord以外の素晴らしいツールがあれば教えていただきたい。

どうかよろしくお頼み申し上げ候。

2016-05-07

http://anond.hatelabo.jp/20160507163959

流し読んで、そうかぁー、ぐらいに思ったけれど。

Wiki日本語英語wikipedia説明を読むと、まんま書いてあって。

  

それまでのマークアップ言語の一つとして、e-mail表記方法などから着想を得ている、ということらしいよ。

https://en.wikipedia.org/wiki/Markdown

  

wikiの出典として下記の記事が使われていて、

http://daringfireball.net/projects/markdown/syntax#philosophy

そこでは、

While Markdown’s syntax has been influenced by several existing text-to-HTML filters — including Setext, atx, Textile, reStructuredText, Grutatext, and EtText — the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

Setext, atx, Textile, reStructuredText, Grutatext, and EtText とか、初めて聞いたけれど、そんな幾つかのマークアップ言語

最大の影響を与え、着想の元となったものは、平易なプレーンテキストe-mailの書き方です。

みたいに書いてるね−。

物知り元増田に素直な増田質問してくれて、分かりやすくなったヨ。

(つうか、元増田よりも、はてな記法に習熟してそうな増田だな)

2016-03-28

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います

p.4
  • HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
  • gulpのgは小文字なのでよろしくです。
p.5
p.6
p.8
  • EditorCodingってなに
p.9
  • コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
  • npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです?
    • まぁ、この後gulpタスクについて出てるんでしょう……
      • 出てこなかった
p.10
p.15
p.16
p.18

コード品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

  • HTMLの話ですよね? コード品質が維持されない難読化や最小化やコンパイルってなんだろう。
  • あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。
p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

  • その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
  • いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
  • あと日本語が変なんで、それも。
p.20
p.21、22
p.2324
  • .editorconfigにどう書けばいいかをだな……。
p.25
  • HTMLルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
  • Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
  • でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。
p.26

正しいHTML

  • HTMLの正しさとは?
  • 参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。
p.27、28
p.29、30
p.31
p.32
p.36、37
p.40

CSS教科書

p.42、43
p.44、45
p.49、50
p.57、58
  • HEXの短縮は規定しなくていいと思います
  • ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
  • gulpでできますし、ググれば出てきます
  • ちなみに、#f00よりもredの方が1バイト少ないんですよ。
  • 容量削減は人が思いつきでやるには不十分なのです。
  • そんなのはビルド時に機械がやればいい。
  • 容量の削減を理由に人の行為制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。
p.61、62
p.63、64
p.71
p.72、73
  • FLOCSSとMindBEMding共存させるなら、書くべきことが足りなすぎませんか。
p.73

block__element__elementは使用しない

p.78、79
p.80、81
p.87

GoogleChromeなら変換時に右側にマーク

p.96
p.98

svgにすることで1つの画像でまかなえる場合svg使用する

p.102
  • ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
  • Jadeについては何かルールは設けないのでしょうか。
  • JavaScriptについては……?
  • そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
  • 誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。
  • 結論:いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

2016-03-26

増田だけどこんな日記ホットエントリ入りして何が面白いの?

意識高い系スライドショーみたいにまず自己紹介が来ると思った? しねーよ。匿名だよ。

つーか、こんなフォントが超ちっちゃいテキストエリアで、ほとんどテキストしか書けないクソみたいなUIサイトで、

はてな地方だかはてな痴呆だかよくわかんないマークアップ言語強要されたあげく、

延々仕事愚痴だかプライベート愚痴だか知らんが、よくわからんゲロみてーなもんを吐き出してる連中がいるってことがマジ信じらんない。

Anonymous?(アノニマス?)とかいハッカー集団みたいな名前も気に入らないし、最近上場ゴール果たしたとか噂されるはてなのものも気に食わない。

そしてたぶんこういうクソみたいな日記でさえ「またミイラ取りがミイラになったよ」「増田にようこそ」「土曜日の昼下がりに投稿乙」とかブコメついて

むなしく消費されていってしまうんだなと思うと怒りさえ沸いてくる。

ちまたではプロブロガーなどといって、カネに変えるために延々クソみたいな文章をひりだしている輩が存在するらしく、そいつらにも怒髪天である

求めているのは話題性か? 身内ウケするレトリックか? サロンに通って金を落としておいて、自分だけは起業家気取りか? 笑えるな。

つーか、この増田をちらっと見てにやけた顔してるお前。そうお前だよ。お前に言ってるんだよ。こんな日記の何が面白いの?

もっと生産的なことに時間を使えよ。お前の人生はそんなものなのか?

2015-04-12

クリエイター気取りのディレクター

クリエイター気取りのディレクターって何なんですか?

デザインマークアップもろくにできないのにWEB業界ディレクター職についてる人ってけっこういますよね。

知識も中途半端で、強いて言うなら見積もりと進行管理プロという立ち位置なのでしょうか。

そういう方の中で、進行管理をちゃんとやらずにAD気取りのディレクターがいて腹が立ちます

相談無くスケジュールを切り詰めるくせに、デザインや動きには細かい注文をつけてきます

もちろんそれで結果的クオリティが上がるならいいのです。

でも、進行管理がいい加減で、閉めきりや提出物の文言や細かいチェック、クライアントから情報に過不足がないかどうかなどの確認は結局制作者がやっているので、制作時間がかなり減ってしまます

実際はすごく手間がかかる作業でも、工数がよく分かっていないせいかものすごく少ない時間見積もってしまったりします。

そんなすぐにはできません、と言うと「言い訳するな!」と言われます

制作時間が減る分、要件を満たすので精一杯になり、当然クオリティは下がります。そしてそれを見たディレクターますますかい注文をしてきます

クオリティが低いものにチェックが入るのは当たり前ですからしょうがないのですが、時間で解決できる問題ばかりなのですごくフラストレーションがたまります

クライアントの言うままに時間を切り詰められ、中途半端ものを提出させられ社内でダメ出しをくらう…その連続で、制作チームはもううんざりしています

あなたたちはオペレーターなのか?自分の頭で考えろ!」と度々言われるのですが、考える暇も与えない状況を作ってるのはその方のように思えてなりません。

制作チームからは陰で社内顧客と呼ばれています

しかし実際、その人に見せてるものクオリティが低いのは明らかですから、こちらも強くは言えません。僕たちの仕事が遅すぎると言われればそれまでなので。

デザイナーが素早く美しくデザインし、僕らがが早急にかっこよく動きをつけれる能力があれば全ては解決するのですから



そう思ってはみてもストレスがたまります

ADでもTDでもなくディレクターなんですからプロディレクターとして制作チームの能力に見合ったスケジューリングをして欲しいです。

そしてデザインや動きについてはプロである僕らに任せて欲しい。

もちろん何かおかしければ指摘があって当然だと思うのですが、その前にまず自分仕事をしっかりすべきではないか、と思ってしまます

これは僕らの我がままでなのでしょうか。

はっきりいってディレクターって、作る能力を持ち合わせていない人がクリエイティブな気分になれる気持ちいい職業ですよね。

それに利用されているのかと思うと腹が立ちます

この気持ちを上司に伝え、ディレクター指導してもらおうか迷っています

こんなことを伝えても「あなたたちのクオリティが低いからその管理に手一杯なのだ。」と言われたらそれまででしょうか。

ほぼ毎週土日も奪われていますし、進行管理おかしいのは明らかだと思うのですが。

甘えるな、この業界はどこもそんなもんだ。」なのでしょうか。

2014-10-28

facebookでもtwitterでも書きづらくなった

会社の人,取引先,同級生など皆がfacebooktwitterアカウントを持つようになって,好き勝手書くことが難しくなってしまった. 匿名ダイアリーなら,きっと大丈夫だろうということで,今まであちらこちらにイニシャルトークみたく書いてた内容を,引き続きイニシャルトークのままこっちに書くことにしよう.

で,それはいいとして,この「はてな記法」とかいwiki崩れみたいな微妙仕様マークアップは,難しいな. html を生で書かせろとは言わないが…もちょっと既存マークアップに似せてよ.
でも一応,雰囲気pukiwiki に似てるかな. タグもなんか使えるっぽいから,習うより慣れろで,何か書くしかないか.

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2014-09-13

WEBデザイナは糞

ほとんどのWEBデザイナって糞みたいなCSSしか書かないしJavascriptは書けない。1ファイルに何千行と書き、コピペ蔓延して破綻していることを直視しないでそのまま開発続ける。

プログラマは、リファクタリングメンテナブルについてとても関心が高い。D.R.Yなんてのは共通認識

一方でWEBデザイナってどうしちゃったのさ。いつまでFTPデプロイみたいな思考してるんだよ。

糞みたいなCSSをどうしてメンテし続けるの?明らかな負債をどうして溜め続けるの?馬鹿なの?

から、お前らWEBデザイナはWEB開発にはいらないよ。

俺らプログラマCSS書くしマークアップもするよ。そのほうがテンプレート効率的に回せるしな。

CSS設計教科書を読んでる。プログラムと考え方似ているかおもしろいな。

バイバイWEBデザイナ。せいぜいWordPressと仲良くしてろよ。

2014-08-01

一発当てた個人開発者をまとめるWebサービス作った

http://individualist.link/ (←ドメインかっこいいでしょ)

居酒屋にて 〜

A「やっぱり若者が稼ぐにはアプリ作るしかないと思うんですよ」

B「あー分かる」

B「スマートフォンアプリWebアプリでもいいの?」

C「ゲームは当たると大きくていいよね」

A「Webアプリでもいいです」

B「当ててそれで暮らしてる人見ますね。羨ましい。」

A「いいですよね」

A「そういう人の話聞いてみたいんですけどなかなか出てこないですね」

B「当てた人が人前で自慢するメリットないからねえ…」

B「どういう人がどういうサービスで当てたのかまとめたい」

A「いいですねえ。Wiki 的な」

B「Google Docs とかでやってみる?」

A「おお、やりましょう」

B「Webサービスにしてもいいかも」

帰宅 & 1時間後 〜

B「できた」

B「ドメイン取ろう」

B「http://individualist.link/

アルコール入ってるから話のディティールうろ覚えだけどこんな流れで作りました

やっぱり若者が稼ぐにはアプリ作るしかないと思う。

当てたいなら先例を見るのが一番参考になるはずだし、僕は個人で作ったもの流行っているのを見るのが好きだし、そういうのとても興味ある。

このサイトを見ていると、どういう人がこのサービス作ったんだとか、これ個人で作ってたんだという発見があっておもしろいと思います

時間で出来た

時間で出来たというのはほとんど誇張ではなくて、デザインに拘る時間サーバーに設置する時間を抜かせば本当に1時間でできます

せっかくなのでちょっと開発について書きます

このサイトコーディングに使う大まかな作業をまとめると

データベース接続

Twitterアカウントユーザー登録

画像保存

タグ付け

JavaScriptで動き付ける

CSS整える

HTMLマークアップ

デザイン

というような感じになる。これらを実直にいちいち実装してたら1日で終わるか分かりません。

本を読む一番はやい方法は、文字を読まないことです。

コーディングせずにライブラリを使いましょう。

ちょっとコードが書けると実装する道筋が思いついちゃうからライブラリを探す考えに及ばず実装しちゃう事があると思います

そういう事は避けて、アプリを書くならアプリ本体を最小に済ませるか、ライブラリ自体を作ることに力を入れましょう。

こちらのサイトではRailsのレールに乗っかって開発しました。

以下の例はRailsを使った方法ですが、モダンフレームワークを使っているのであればだいたい似たような話になると思う。

ライブラリで組み立てよう

Rails

手に馴染んだフレームワークがあるならなんでもいい。

クソ小さなロジックと数ページしかないならPHPでもいいけど、

とにかくはやく作ることがしたいなら何かしらフレームワーク使ったほうがいい。

秘伝の Rails Application Template を用意しておくのも良い。

データベース接続

モダンフレームワークなら何も考えずにデータベース接続できるはず。

Rails なら config/database.yml に接続情報書いて rake db:create && rails g model User name:string です。

scaffold 使うと更に早くできます

Twitterアカウントユーザー登録

OmniAuth gem を使います

ソーシャルアカウントログインする要件が出たら、何も考えずに「あ、OmniAuth」となりましょう。

Device gem を使うと更に早くできます

画像保存

Paperclip gem を使います

画像保存が必要になったら反射的に「Paperclip か CarrierWave どっにしよう」となりましょう。

ファイル保存とか変換をいちいち実装してたら朝が来ます

タグ付け

ActsAsTaggableOn を使います

has_many :through のめんどくさいタグの実装ですが

これ入れて rake acts_as_taggable_on_engine:install:migrations && rake db:migrate を打てば一発で完成します。

JavaScript で動き付ける

早くつくりたいんなら JavaScript は捨てましょう。

少なくとも生の JavaScript 書く時代ではないので CoffeeScript 使うと良いです。

CSS 整える

とりあえず Bootstrap 入れましょう。

クラスの付け方を覚えちゃうCSS 弄って HTML リロードして確認なんてことしなくても形は整います

Bourbon gem 使って mixin ライブラリ組み込んじゃうのもいいですね。

HTML マークアップ

HTML 書くのやめましょう。

Haml や Slim のようなテンプレートエンジンを使います

Slim が一番タイプ量少なくておすすめ

Zen Coding でもいいけど、結局出力されるのが HTML じゃ見通し悪くて辛いと思う。

Web Components の時代になったらもっと簡単になるんだろうな。

デザイン

こればかりプロっぽいものつくる自信はない…

ただ、Webページやアプリというのはだいたい決まったパターンがあるので、いろいろな事例を見るとよいでしょう。

正直レイアウト自体は他のサイト真似るのは悪くない判断だと思います

しろその方がユーザーにとって慣れ親しんだ分かりやすサイトでもあります

http://individualist.link/場合http://www.producthunt.com/ を異常なほど参考にしました。

まあここまで書いてなんだけど、前提知識として Rails が使えるようになってないといけないのは敷居高くて悪かったと思う。

僕も最初アプリ作るのに途方も無い時間かかってた。

慣れればはやくなるから、たくさんアプリ作って一発当てよう。

思いついたときにすぐ作れるようになれるといろいろ捗るぞ。

なお、今回つくったこのサイト、ぜひともみなさんにも投稿していただきたいのですが現在投稿者承認制としております

質を保ちたいので、捨て垢に荒らされても困りますからね。

私本当に個人が作って運営しているというアプリサイトというのが好きでして、

こちらのサイトリストアップする行為に儲けやがってといった悪意は一切ありません。

私にとっては好きな人達をまとめるサイトなので質はしっかりしておきたいのです。

2014-04-28

http://anond.hatelabo.jp/20140428150354

HTMLは見た目だけ綺麗にできりゃいいってもんじゃない。

意味に合わせた要素でマークアップして、後からスタイル適用するんだからテキストエディタで作るのが正しい。

2014-02-02

Web制作フリーランスってさ

その人のブログ見ると

Web制作およびコンサルタント

サーバーサイドおよびフロントエンドエンジニアリング

ソリューションディレクション

とかたいそうなこと書いてる人が多いけど蓋を開けてみると酷いことが多い


Web制作およびコンサルタント

WordPressで作った簡単なテーマ or 既存テーマを少し弄った程度でコピペ

コンサルタントなんて響きだけでネットで得た意識高い系をそのまんま喋るだけ

しか技術が伴ってないのでやれることは少ない

サーバーサイドおよびフロントエンドエンジニアリング

HTMLはある程度わかるが例えばHTML5なら仕様に伴ったマークアップはよくわかってない

CSSIE向けに調整できると言っても~.jsライブラリコピペするだけで実査の動きはわかっていない

動きのあるものjQueryコピペするだけ

ソリューションディレクション

いいたいだけだろ、と


もしかして田舎だとこういう人達でも食っていけるってことなのか?

2014-01-22

コード自動生成とか幻想すぎる(ような気がする)

http://anond.hatelabo.jp/20140121235137

僕は専門家じゃないからよくわからないが以下のように考えている

たとえばよく言われる

モデル記述言語モデル記述したらコード自動生成されるのでプログラム不要って話は、

C言語が.sを生成するのと同じなのでそれはコンパイラであって概念的には昔からある話。

C言語抽象度低くてむつかしいというなら抽象度の高い言語を使えばいいというだけにしかならん。

GUI設計すれば自動的コードができるようにならんの? って話はUIビルダとか昔からそうだったじゃん。

でもGUIで作ったやつってバージョン管理システム管理しづらいからマークアップ言語記述できるようにほうが便利ってことにみんなが気付いて、結局テキスト記述できるようなのを一般的にしようってのが2004年2005年くらいの話

2013-11-01

http://anond.hatelabo.jp/20131101031728

いや、だから、「ブレインワーク」をしているという貴方様が、

はてなマークアップさえも理解できず、

その上、独自のマークアップだかで引用を示そうというも、

何故か引用のほうではなく、自分の方に>を書いている。

これはもはや、普段メールなども他人とはしてないのでは?との疑問も得られる。

まりは他人と交流さえしてないのでは?

その上、「ブレインワーク」で考えるための頭が重要にもかかわらずこんな時間まで起きて益田などしている。

これがほんとに会社瞑想2時間しても何も文句言われない結果を出している「ブレインワーカー」のすることだろうか?

結局はただのニートの戯れに過ぎなかったのか、ということが分かってしまった。

ということなんだけど、なんか反論ある?

http://anond.hatelabo.jp/20131101022626

まあ、がんばれよ。

ぶれいんワークとか言ってる割に増田の書き方すら理解できないみたいだが。。。

(仮にマークアップなしの状態での引用を表そうとしてるんだとしても自分の方を引用みたくすると言う意味不明行為をしてるし。。。)

2013-09-22

http://anond.hatelabo.jp/20130922000614

元増田です。

  

そのためのデータ管理という項目をコンピュータ教育指導要領に含めるべきだって話です。

代替オフィスへ移行しても「名前重要なのは変わらないですし、互換性問題からマークアップ」も必要とすべきです。

  

マークアッププログラミング型推論のように行われる可能性は軽量マークアップ言語の登場からあり得ない話では無くなってますけど、それに至るまでは時間が沢山必要だと言って良いはずです。

僕は別に憲法のような確固たる可能な限り変えるべきではないルールとしてデータ管理からコンピュータ教育を推しているわけではないです。

  

ただデータ管理は少なくとも僕の寿命が尽きても広く使われるはずだ。この意見IT業界関係者ならば否定のしようがないことだと思います

SF的な量子コンピュータが使われようがデータ管理はされるし、一般ユーザはしなければならない。違いますか?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん