  |
はてなキーワード: マークアップとは
「～～大学の研究チームが、”AI・人工知能”によって～～を可能にする□□を～」とか、
「株式会社～～が”AI（人工知能）”による自動化を本格化～」とかしばしば聞くけど、
「AI」と略してるのにわざわざ「人工知能」と付け加える事に違和感を感じる。というか長ったらしいからやめてほしい。
今の時点で「AI」と聞いて「人工知能」を連想しない人なんてほぼいないだろうし、いたとしても「人工知能」と付け加えたところで今更何のことだか意味不明だろうし。
一昔前は「XML（拡張可能なマークアップ言語）」なんて余計に意味不明になる付記があったけど、こうしたマスコミの過保護な付記ってそろそろやめてくれって思うけど、一般にはどう思われてるんだろう？
https://tech.pepabo.com/2019/02/19/pay-revision-for-engineers/
「エンジニア専門職およびエンジニアリングマネージャー職の年俸を一律200万円アップしました」
なるほど。専門職のエンジニアリングスキル高い人が評価されるのはよいことだ。
もともと給与は低いらしい？（ブコメより）ので結果どれくらいになったかは知らないけど、
200万あがったなら少なくとも市場的に標準くらいにはなったのだろう。
自分はペパボとは関係ない1都3県のどっかにある1受託会社の、1デザイナーなんだけど、
昨今の流れに乗っかって、会社は去年、技術もちゃんと評価します的なことを表明した。
ほぼあがらなかった。（お気持ち程度2〜3,000円/月）
一応、プロジェクトではメインでデザインしてるし、クライアントにゴリゴリ提案したりしてるんだけど。
デザインもディレクションもマークアップもしてる。フロント何でも屋感。（フロントエンドエンジニアレベルにはできないけどね）
デザイナーは対象外だったってことなのか、そのあたりのディレクションスキルやデザインスキル、マークアップは対象外ってことなのか。。。
ペパボのデザイナーさんたちは、あの記事見てどう思ったんだろう。
最近、エンジニアが人手不足だ、採用できねえ、評価あげよう、給与あげよう、みたいな記事とかよく見るけど、
デザイナーはそこまででもない。そもそも人口違うから仕方ない。
優秀な人はきっと自分のスキルをきちんと発信して高い評価もらってるか、あまり発信がうまくない人はそっとフリーになるのかもしれない。
エンジニアと比べても仕方がない。そもそも土台が違う。需要も違う。
でも一緒のチームにいるし、なんだかなって思ってしまう。
まー、今の会社は多分辞める。
自分のデザインのズレとかは全く気にしないくせに、こっちがマークアップしてWebで見ると「ここのピクセルズレてる」（あほか、おめーが小数点以下のピクセルを気にせずつくるからじゃろがい！）とかいい出しやがるので、デザイナーといいつつ自分が気の済むままに絵を書いちゃう奴の頭に雷落ちねーかなぁと思いながら過ごしてる。
しかし、デザインの勉強もやってねーのにデザインの事語るやつももっと嫌い。
伝わらなければデザインじゃない？アホかよ、おめーがメインターゲットじゃねーだけだろ。
伝えたい層に伝えるのがデザインなんだよ。
そもそも「デザイン」って一口にいうけど、デザインは色んな場面に使われすぎてひとことで言い表せないから俺の「伝えたい層に伝えるのがデザイン」も間違ってるっていうはなし。そもそも万人に伝わるデザインはユニバーサルデザインとか言ってまた人種が違うやつ。キャラクターデザイナーがUD考えてキャラデザするかっつーの。
WordやHTML+CSSで文章を書くのと比べて、桁違いに書きにくい。
お蔭で後年SQLに出会った時は、記法のセンスの素晴らしさに感動したわ。
何故なのかは知らないが、バックスラッシュに中括弧に$に^に、fracみたいな覚えにくい予約語のオンパレードにその他諸々、記法があまりにも暗号的すぎるんだよ。
マークアップ的要素があるくせに、XMLやHTMLよりも「どこからどこまで」を遥かに把握しにくいし。
あと、記法の問題だけじゃなく印刷に持っていくまでの処理もマジめんどくさいわー。
WYSIWYGを捨ててかかってるだけでも十分めんどくさいのに、dviにしてレイアウトを視覚的に確認しようとするだけで「文法間違ってます出力できませーん」とか、いい加減にしろアホ！と何度思ったことか。
こういうTeX使ったことある奴なら当たり前に経験している使いにくさを「インターフェース」と言ったのに、エディタの問題などと矮小化して捉えられるのは、正直言ってメチャクチャ不愉快だわ。
てか、viでもemacsでもなんでもいいけど、こんなのどんなエディタ使っても使いやすくならないだろ。
いろいろツール入れれば多少は負担が軽減されるのかも知れないが、そんなふうにいちいち環境整える手間を掛けてまでTeXで書く理由なんて微塵も感じられないから。
車の運転がAT全盛の時代にあってMTに凝るくらい趣味的かつ滑稽な話だよ、TeXは。
「C言語に対する最新最良の処方は、可能な限りC言語を使わないこと」というのは有名だが、これはそっくりそのままTeXにも当てはまる。
※ここでいうフロントエンドとは、HTML/CSS/JS でデザインをもらって実装する人のことです。
デザイン再現するために、サーバー側に実装して貰う必要があるとき、
「デザインがこうなってるんで◯◯◯◯◯ください」といって、サーバー側とデザイナーの伝書鳩みたいになるとき。
だいたいデザイン再現のためにサーバーの人に相談しにいったら「無理です」ってぶっきらぼうに言われることが多い。怖い。
フロントエンドのこと見下してる人が多いと感じる。
お前の書いたCSSとHTML、インデントもぐちゃぐちゃで運用性も低いからちゃんとBEMとか学んできてから書いて…。
作ったのはデザイナーのデザインなので、自分が作ったという感じがしない。
自分は一体なにをやってるのかとおもうことがある。
めんどい。
マークアップ、もう動けばいいじゃんてなる。
フロントエンドエンジニア、言われたからやる、ということが多い気がする。
サーバサイドから見下され、デザインは自分でつくったわけじゃない。
好きだったはずのフロントエンド。
もう好きじゃなくなったのかな…。
攻略wikiっぽくない「自称攻略wiki」を見かけるようになった - シロクマの屑籠
http://p-shirokuma.hatenadiary.com/entry/20171221/1513820193
最近据え置きゲーをやっておらず、スマホゲーとブラウザゲーばかりの増田です。
ウィキペディアをwikiと略すな、は十分周知されているとは思いますが、wiki的な編集過程でない普通の
攻略サイトを攻略wikiと呼ぶな、というのは言われてみるに確かにそうね。
wikiとは何か。
多くのウィキに共通する特徴を以下に掲げる。
・ネットワーク上のどこからでも、いつでも誰でも文書を書き換えることができる。
・文書の書き換えに最低限必要なツールはウェブブラウザのみである。
・ウィキ特有の文書マークアップはHTMLなどと比べて簡潔なので覚えやすい。
・同じウィキ内の文書間にリンクが張りやすくなっており、個々の文書が高度に連携した文書群を作成しやすい。
・大抵は、変更の事前許可を必要とせず、ウィキのあるサーバに接続できる人に開かれている。実際、ユーザアカウントの登録を必要としていないところも多い。
と言われているんやで
２．従来の出版社系ゲーム攻略サイトがwikiを名乗っている系
３．特に増えている新興ゲーム攻略サイトがwikiを名乗っている系
それぞれについて少し語る。
個人のマニアが立ち上げた攻略サイト。新声社や電波新聞社といったプレイヤーもいた攻略本界隈。
友達の兄ちゃんに嘘テク教えられたり、実際は小数点以下の確率で盗める。
こんなゲームにマジになってどうすんの。
企業のネットが星を覆い、電子や光が駆け巡っても、個人攻略できるレベルを超えたボリュームのゲームを
一人で無理ならみんなで情報を持ち寄ろう、ネットは匿名で平等で集合知でウィンウィン。
2chのゲーム本スレのテンプレに貼られているのがこういう攻略wiki。
wikiに貼ってある広告のアフィってwiki開設者に入ってるんじゃね？
真偽は定かではないが、ゲーム攻略wikiは儲かる、他サイトのデータをコピペして作成し、ライバルの方には
デタラメや煽りを書き込んだりして評判を落とす。トップ攻略の地位をもぎ取ればウハウハ、という手法を
世はまさに大嫌儲時代、モンキーDアフィの五武海はちまjinやらおんハム速ニュー速VIPが追放されたり
2ch政府の内紛分裂があったり。
そんな嵐が過ぎて見回してみれば、１型攻略wikiは凋落して、３型の全盛期。
ゲーム単体の攻略も大変だが、リリースされるゲームの数も膨大。
世はまさにガチャゴールドラッシュ、だけど一攫千金でゲーム開発するより、シャベルとジーンズのテンプレで
儲ける方が固い商売だよね。
２．WARNING!! A HUGE BATTLESHIP KADOKAWA IS APPROACHING FAST
そうボスはカドカワなんだ。たつきは帰ってこないんだ。君も人生と向き合うときなんだ。
これが、アレでしょうね。出版社系の。攻略wikiの。なれそめ？初出？元凶？根源？大丈夫？
Wikiサイトっぽい外見してますがライター執筆記事やファミ通企画の攻略動画へのリンク盛り盛り。
一般人はツイッター連携で掲示板とかコメント欄には書けるけど記事編集は無理そう？
基本的にライターに書かせているであろう攻略サイトをwikiと呼ぶのは、SEO有利・プレイヤーに
親しみを持たれるからではないかと思う。が、外注ライターの個別記事をいちいち社内で検収して
からアップロードといっただるいスタイルを取らずに実際にwiki形式で登録ライターが直接編集
しています、ってことかもしれない。
ファミ通WikiはGzbrainが運営。カドカワ傘下で浜村編集長の会社です。
で、出版社系言いますけども１．でちょっと触れたようなかつて攻略本出してた系の出版社は死に体で。
お家騒動で分裂した電撃ＭＷも、富士見書房もファミ通文庫もオタク系は軒並みカドカワの軍門に降り、
時々絶妙なインタビュー記事などを載せる電ファミニコゲーマーもドワンゴ運営。
電ファミWiki
https://wiki.denfaminicogamer.jp
これwikiシステムの貸し出しやってますよ。って形式ですね。
あとは出版社でゲーム関係出してるってなるとVジャンプとかスクエニとかですかね。
本屋行ってもあとはアプリのシリアルコード載ってるような奴と、晋遊舎や三才ブックスのようなのと
wikiを紙に落としこんだ素性のわからない出版社の完全攻略本くらいしかない。
というかね、FF7あたりから10年くらいの、攻略本が売れ行きランキングに載ってきてしまうほどの時代、
アレが攻略本バブルだったんですよ。攻略本の対象ゲームもバンバン売れてたわけですよ。
CDがカラオケBOXブームとかもあってめちゃくちゃ売れてたのと概ね同じ。経済バブルの残り香的な。
３．攻略は再び名人の時代へ
古の昔、連射こそがすべてであり、鋼の定規と16連射が支配する、高橋名人の時代があった。
実際にはハドソン社員の高橋名人はゲーム自体もそれほど上手いわけではないらしいが。
そのハドソン出身の山本大介が作った（※）パズドラがヒットしたけれども、アプリ内には外部の
攻略サイトへのリンクがあったんですよ。ファミ通とAppbank。
これね、パズドラが初めてじゃないとは思うんですけどね、衝撃でした。増田には。
※全くの余談。ゲームは１日１時間という標語はハドソン由来でパズドラでもランダムTIPSで表示される。
ほならね、ペアレンタルロックで１時間制限させてみろって話でね。
ゲームを作ったのは誰か論争、これ法隆寺は誰が建てた、みたいな話になるので難しい。
パズドラは山本Pが手動して作ったが、あのドロップが吸い付く操作性・移動に伴うクリック感ある音と
コンボエフェクトの快感、を実装したコアプログラマーはアプリリリース後に抜けてしまい穴を埋めるのに
２年位かかっていたのではないかと増田は増田は勝手に思うのです。なんでかつうと、パズル操作盤面内へ
の改修がその間ほとんど行われず、イラストとステータス変えたモンスターの追加だけで２年間過ぎて
いったから。間を持たせるためにイベントとか生放送で盛り上げてごまかすぞ、ってニコニコみたいな話。
いや、それでガチャ回るんだから美味しい話だし、ゲーム的にも余計なことしないでくれて平和で良かった
と今は思うけれども。その間に、W、チャレンジ、3DS版、アーケードなどパズドラアプリの再発明で繰り返し
修行してようやく操作に違和感もたせないレベルで盤面システム（十字消し・立て追い打ち・雲・帯・
ルーレットなど）いじれるようになったのかなと。３マッチパズルだけど何か納得いかない消え方（ワロス消し）
についても修正されたのその後なんだよね。
コアプログラマーが重要ってのは拡散性ミリアサの終了事由のインタビュー記事を参照されたし。
指導的地位といえばパズドラのエグゼクティブPであるガンホー森下社長、わしが作ったと言っておりパズドラは
こうして産まれたとのマンガでもそう描かれている。消費者庁コラボhttps://anond.hatelabo.jp/20170719231854
での謝罪の責任者名は森下、それ移行の山本Pの対外的露出自粛も、作った男の主導権争い的な面もあるのでは
ないかとはゲスの勘ぐりですね。極み極み。
閑話休題。
攻略リンクの話に戻ると、ファミ通はわかる、みんな大好きマックスむらいのAppbankは何もんだ？
iPhoneケース販売とかアプリ紹介とかやってるんだって、へえ。
アプリリリース当時はAppストアの規制もぬるく、ダウンロードランキングの売買アプリ（他のゲームインストール
するとゲーム内通貨発行）とか、シリアルコードとかセーフだったんで、単純に攻略データへ誘導すると便利だね、
以上の素敵なサムシングの期待があったのかな。
Appbankはwikiを僭称せずに攻略記事を書いてるようです。
後にパズドラのアンケートでは、攻略の際の参考にするサイトとしてどういうところを利用しているかの問に
ファミ通アプバンの他に、appmedia、gamewith、game8などが選択肢に上がっていた記憶がある。
こういう攻略サイト系、幅広くゲーム攻略してまして、運営は会社組織でやってまして、攻略ライター募集してまして、
ライターには石購入補助金も出まして、何それガキの小遣いじゃないか。
ゲームアプリは随時更新され日々攻略必要、またリリースされる数も半端じゃない。
どれがヒットするかわからないからツバつけておかないと後発では攻略覇権取れない。
きららファンタジアだってぐだぐだから離陸したFGOのように羽ばたくかもしれない。
あるゲームでは充実した攻略情報が載っているサイトでも、他のゲームではテンプレ作って終わりだったりするのは
ライターの層の厚さの違いによるものなんだろうねえ。
そして栄枯盛衰、他サイトにどうしても勝てそうもないとなれば撤退やむ無し。
【FGO攻略wikiからのお知らせ】
2017年8月25日を持ちまして、FGO攻略wikiの更新を停止いたしました。短い期間でしたが、これまでのご利用ありがとうございました。
https://game8.jp/fate-go/144602
これね、一つの攻略サイトは適当でも複数横断して集計すればまともな結果でるんじゃね、と星4鯖配布の時に調べてて
みつけた。ニトクリスもらいました。
https://anond.hatelabo.jp/20170921034548
ああ、終わりってこういう風に来るのか、って微妙な気持ちになったね。
さらに話題転換。
Appbankといえばユーチューバーマックスむらい。ユーチューブの前はニコ生のガンホー公式放送でのメインプレイヤー
もやっていました。彼はそこそこ上手い程度ですがAppbankからはユーチューバーとしてコスケとかが出てきたようです。
ヒカキンもヒカキンゲームズやってますし、先述の攻略サイト運営会社の中にもユーチューブやAbemaTVのタレント事業
手がけてる会社もあり、サイバーエージェントやらGMOと取引あるところもあり、界隈ですなあ。
時代は上手いプレイヤー個人やゲームプレイ動画の攻略に移っていこうとしてるのかなあ。
プロスポーツとしてのeゲームも業界団体が統合？して来年から本格始動みたいですしどうなるんでしょうね。
情熱あるゲーマー有志がボランティアで攻略してどうこう、っていう集合知の善性は容易に横から収奪されて熱量が失われる。
上手い個人はプロゲーマーとか、ユーチューバーとしてマネタイズできる。
ゲーム上級者の増田があったけれども我々凡人は商業の攻略wiki見て満足すればいいんじゃないか。
攻略本は出版社がライターに金出して作って、プレイヤーが金払って買った。
攻略サイトは運営がライターに石援助して、プレイヤーPVで金を稼ぐ。
「そこに何の違いもありゃしねえだろーが。」「違うのだ！」
どこに線をひけばいいかわかる人いる？それ、はあちゅうに教えてあげてね。
増田としては資本がどうであれ有用なデータがあるサイトが検索上位に来てくれればいい。
WELQのように信頼できない情報や、はてなキーワードの未作成ページにランディングすると
いちいちnaoyaは嫌いだけど、と前置きつけながら告訴したくもなる。
嫌儲の問題とか村上隆の金の話https://anond.hatelabo.jp/20170925233933とかしようと思ったけど時間がなくなった。クエスト回さねば。
UIの問題としてとらえると、HTMLはテキストマークアップ言語であり、主体はテキスト。
ここにポイントがある気がする。
もし、Webを記述する言語がアバターを使ったシステムを構築するものだったら、
今更言ってもしかたないけど、筋が悪い技術が広まって変えられなくていろいろ災難起こしてるのってあるよね。
Cが広まったのとか。
昔はコンパイラ技術が低くて、ああいう言語が効率よかったけど、すでに90年ごろには最適化技術が発達して「人間がテクニックを使って最適かするより素直に書いてコンパイラに最適化させたほうが実行速度が速くなる」とか言われてたし、Macなんか開発言語Pascalだったし。
OSやミドルウエアが(せめて)Pascalで書かれてる世界線だったら、いまのソフトウエアの脆弱性は大幅に減ってたと思うわ。
あとマークアップ言語のHTMLの上で動的型のJavascriptを動かして、フロントエンドのプラットホームになってしまってるのとか。
一時期、ネットアクセスはスマホアプリから行うのが一般的になって、Webは衰退するって観測で、いい方向に向かってたけど、最近はアプリ開発までDOMの上にReactとか積み上げてJSでやろうみたいな流れがあるし。
業務アプリなんかもPHPやJSの人に、昔のクラサバのほうが開発効率よくてユーザーの使い勝手もよかったって言っても全く理解できないみたいだし、どんどん悪い方向に向かってるな。
Webサイトのクロスブラウザ対応に携わったことがある者だけがIEに石を投げなさい
http://anond.hatelabo.jp/20170508211030
最初から追記（元増田がどういう環境でどういうソースから電子書籍を作ってるかわからないので、以下は自分のところの話）
新刊は電子データなのだから電子書籍にするのも簡単だろとか言う方々はかつてのクロスブラウザ対応のことを考えてもらいたい。
「HTMLは電子データなんだからIE6でレイアウトが崩れないようにするなんて簡単だろ」って言ってんのと同じなんだよ。
InDesignのEPUB書き出しは現状全く使えず、まともなEPUBを吐いてくれない。
となるとDTPの流し込み用テキストをもとに電子書籍データを作ることになる（そうじゃないところもあると思うが）。
もちろんInDesignから書き出したPDFを電子書籍でございと売ればこの手間は省ける。
しかしリフローしない電子書籍、文字を拡大するとページの一部しか読めなくなる電子書籍なんて読みたくないでしょ?
印刷用のPDFはデザインを簡素にして、Re:VIEWから直接出力できる程度の装飾しかしないなら話は簡単だ。
同じソースから紙の本向けのPDFと電子書籍用のEPUBを同時に生成できる。
その場合でもIllustratorで作ったベクターデータの図を載せる場合、PDF向けのEPSデータ（1色）とEPUB向けのPNGデータ（RGB）が必要だ。
そうなるとPDFとEPUBで同じ場所にきちんと同じ図が掲載されているかのチェックが必須となる。
図に修正がかかった場合、EPSとPNGの両方を間違いなく修正したかチェックが必要。
そんななので、紙のデータと電子書籍のデータをワンソースからサクッと作れる世界が来るまではもうちょっと時間がかかりそうなんだ。
日本のお役所がPDF大好きなのは、知っている。霞ヶ関から吐き出される有効な資料は、ほぼpdf！
一方で、e-statなどでは、ネ申エクセルや方眼エクセルとは、別の方向でcsvデータを公開している。
今、株価が上昇しているIT企業様は、PDFとhtmlとを比べるような使い方はしていないのでは？
世界は、IT企業、htmlとPDFとを比べたらどちらを重用しているのか？
googleがjava script 推しのJQueryを良く使ってるし、これからは、人工知能の時代だから、xml形式とか、マークアップ言語は、良く出てくると思うよ。
Facebookはphpなんでしょう？リア充御用達で、Twitterよりも株価も資本も安定している。
これからは、you tubeとかLINEみたいなツールがどんどん出てくるから、先のことは分からないよね。
オープンソースでもGit hubみたいなツールが使われているんだし。。
元々HTMLが書けない素人向けの仕組みだぞ。Wikipediaでもゲーム攻略Wikiでも素人が覚えて編集してるのに技術者が何言ってんだ。
第二に、保守以降、一つのシステムに複数の改修案件や故障対応が並行するようなことはままあることだが、ソースはSVNなどで管理できるが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である。
また、設計書作成に使用するツールでExcel、Word以外の素晴らしいツールがあれば教えていただきたい。
どうかよろしくお頼み申し上げ候。
流し読んで、そうかぁー、ぐらいに思ったけれど。
Wikiの日本語や英語のwikipediaの説明を読むと、まんま書いてあって。
それまでのマークアップ言語の一つとして、e-mailの表記方法などから着想を得ている、ということらしいよ。
https://en.wikipedia.org/wiki/Markdown
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の書き方です。
みたいに書いてるね−。
物知り元増田に素直な増田が質問してくれて、分かりやすくなったヨ。
正しいHTML
block__element__elementは使用しない
GoogleChromeなら変換時に右側に△マーク〜
意識高い系スライドショーみたいにまず自己紹介が来ると思った？ しねーよ。匿名だよ。
つーか、こんなフォントが超ちっちゃいテキストエリアで、ほとんどテキストしか書けないクソみたいなUIのサイトで、
はてな地方だかはてな痴呆だかよくわかんないマークアップ言語を強要されたあげく、
延々仕事の愚痴だかプライベートの愚痴だか知らんが、よくわからんゲロみてーなもんを吐き出してる連中がいるってことがマジ信じらんない。
Anonymous？（アノニマス？）とかいうハッカー集団みたいな名前も気に入らないし、最近上場ゴール果たしたとか噂されるはてなそのものも気に食わない。
そしてたぶんこういうクソみたいな日記でさえ「またミイラ取りがミイラになったよ」「増田にようこそ」「土曜日の昼下がりに投稿乙」とかブコメついて
むなしく消費されていってしまうんだなと思うと怒りさえ沸いてくる。
ちまたではプロブロガーなどといって、カネに変えるために延々クソみたいな文章をひりだしている輩が存在するらしく、そいつらにも怒髪天である。
求めているのは話題性か？ 身内ウケするレトリックか？ サロンに通って金を落としておいて、自分だけは起業家気取りか？ 笑えるな。
つーか、この増田をちらっと見てにやけた顔してるお前。そうお前だよ。お前に言ってるんだよ。こんな日記の何が面白いの？
デザインもマークアップもろくにできないのにWEB業界でディレクター職についてる人ってけっこういますよね。
知識も中途半端で、強いて言うなら見積もりと進行管理のプロという立ち位置なのでしょうか。
そういう方の中で、進行管理をちゃんとやらずにAD気取りのディレクターがいて腹が立ちます。
相談無くスケジュールを切り詰めるくせに、デザインや動きには細かい注文をつけてきます。
でも、進行管理がいい加減で、閉めきりや提出物の文言や細かいチェック、クライアントからの情報に過不足がないかどうかなどの確認は結局制作者がやっているので、制作時間がかなり減ってしまいます。
実際はすごく手間がかかる作業でも、工数がよく分かっていないせいかものすごく少ない時間を見積もってしまったりします。
そんなすぐにはできません、と言うと「言い訳するな！」と言われます。
制作時間が減る分、要件を満たすので精一杯になり、当然クオリティは下がります。そしてそれを見たディレクターはますます細かい注文をしてきます。
クオリティが低いものにチェックが入るのは当たり前ですからしょうがないのですが、時間で解決できる問題ばかりなのですごくフラストレーションがたまります。
クライアントの言うままに時間を切り詰められ、中途半端なものを提出させられ社内でダメ出しをくらう…その連続で、制作チームはもううんざりしています。
「あなたたちはオペレーターなのか？自分の頭で考えろ！」と度々言われるのですが、考える暇も与えない状況を作ってるのはその方のように思えてなりません。
しかし実際、その人に見せてるもののクオリティが低いのは明らかですから、こちらも強くは言えません。僕たちの仕事が遅すぎると言われればそれまでなので。
デザイナーが素早く美しくデザインし、僕らがが早急にかっこよく動きをつけれる能力があれば全ては解決するのですから。
ADでもTDでもなくディレクターなんですから、プロのディレクターとして制作チームの能力に見合ったスケジューリングをして欲しいです。
そしてデザインや動きについてはプロである僕らに任せて欲しい。
もちろん何かおかしければ指摘があって当然だと思うのですが、その前にまず自分の仕事をしっかりすべきではないか、と思ってしまいます。
これは僕らの我がままでなのでしょうか。
はっきりいってディレクターって、作る能力を持ち合わせていない人がクリエイティブな気分になれる気持ちいい職業ですよね。
それに利用されているのかと思うと腹が立ちます。
この気持ちを上司に伝え、ディレクターを指導してもらおうか迷っています。
こんなことを伝えても「あなたたちのクオリティが低いからその管理に手一杯なのだ。」と言われたらそれまででしょうか。
ほぼ毎週土日も奪われていますし、進行管理がおかしいのは明らかだと思うのですが。
