golangで商業サービスを書いて世の中に送り出した話

やあやあ。

今回は Go Advent Calendar 2015 その2 の12日目の投稿だよ。

今年のgolangは人気で、その1~その3まであるみたい。

 

11日目の投稿はこちらの方達がされています

 

全体的に技術的にレベルが高い記事が多い中、私は違う視点からAdvent Calendarを書いてみたいと思います。

 

なんで商業サービスにgolangを採用したの?

アーキの設計権限も、言語の採用権限も、全て私にありました。

私がサービスで最も重要なのは、挙動の「速さ」であると考えています。

速いは正義。速さこそ全て。速さとは力である。

それと同時に、ある程度の書きやすさも必要です。作るのは私です。書きづらい言語は避けたい所です。

後は、予算は節約する必要があるので、クラウドで借りれる安いヘボサーバを並列で並べて何とかしたいという大人の事情。ほどほど~良いサーバを数台借りるより、遥かに安上がりなんですよね。

今回私が書くのはサーバサイドのアプリケーション。APIサーバと分類されるものです。

そこでいくつかの言語が候補に挙がりました。

え? C++以外名前が伏せられているじゃないかって? まあ、その辺は想像にお任せします。

 

関数的表現が可能なJVM言語

初心者にしては比較的動くサンプルコードが書けたと思いました。

ただ、どうしても以下の問題を私には解決できませんでした。

  • 安定稼働させるには思ったよりもメモリを必要とした
  • 思ったほど速度が出なかった

安定はしていたのですが、如何せんリソース食う割に速度が出ずに頭を抱えました。きっともっとうまく書ける人も居るんでしょうが、私にはこの程度しか使いこなせませんでした。

後、関数的に書くと私以外の人の学習コストが高すぎるので、エンジニアの並列化がやりづらいという別の問題も。

 

コンパイル不要なメージャーどころのスクリプト系言語

最近最新版が出て速度がかなり改善された言語ですが、私はコンパイル駆動がしたかったので、お引き取り頂きました。

 

そのスクリプト言語と同じような記法で書けてコンパイルできる言語

上記言語が高速化する前に一時期話題になった噂の言語。

ですが、今後もその言語に縛られる事は幸せなのかどうかで悩んで、一旦保留にしました。

 

C++

私はC/C++系の出身なので速度的にはかなり有利な事が分かっていましたが、それと同時にこの言語でネットワーク周りをやると死んでしまいそうになる事も知っていたので、却下しました。

 

そして選ばれたのはgolangでした

golangは満足な速度が出ます。そして、コンパイラがそれなりに優秀です。

ネットワーク周りや暗号処理周りが標準パッケージに含まれており、それらの出来も結構良いです。ここで、ネットワークが必要となるプログラミングにも十分耐えられることが分かりますね。

better Cでもあるので、構造体が使用可能です。「ある」と「ない」とでは全く違います。更に、ポインタ概念も存在します。にも拘らず、メモリの開放は言語にGCが積まれているので、C/C++に存在しがちなメモリの開放に関わる諸問題が起きづらいです。

なかなか魅力的ですね。

また、言語の機能そのものも非常にシンプルで、ちょっと勉強したら書き始める事が出来ます。

 

golangでプロダクトを書くにあたり

最初に行ったのは以下の整備です

  • ビルドスクリプトを作成
  • リリースモードとデバッグモードのビルド分けを実現
  • 自動デプロイの仕組みの構築
  • RDBとの接続回り
  • イベント駆動するサーバ機能とルーティング
  • 外部パッケージのバージョン制御

これだけはしないといけません。しかし、これだけやれば後は書くだけです。

 

ビルド~デプロイ系

ビルドスクリプトを叩けば、勝手にプロダクトがビルドされるようにしておきました。

デプロイはJenkins氏に丸投げします。勝手にgitからリポジトリを落としてきて、勝手にビルドして、勝手に成果物を目的の場所に配信する仕組みを作るだけです。

また、外部パッケージは毎回最新を取得してビルドするようにしました。

私は台数が変動し、IPも固定に出来ない複数台のヘボサーバへ自動に配信したかったので、動的分散デプロイシステムを書いています。

 

RDB周り

gplangには重厚なORMは不向きです。直接SQLを書くことの方が多いでしょう。

 

ルーティング系

良いパッケージを見つけたので、そちらを利用させていただきました。

 

外部パッケージのバージョン制御

恐らく、ここがgolangの弱点。

golangは外部パッケージをコマンド一本で取得して利用できる強みがありますが、この機能は対象リポジトリから常に最新のものを取得してくるという性格を持っています。

golangの設計思想として、外部パッケージは公開した後に破壊的アップデートをしてはならないとなっているようで、利用しているパッケージが下手なアップデートをしてくると死にます。

ただ、私は常に最新のコードを使いたかったので、クリティカルなパッケージのみ、自動取得した後に特定バージョンにチェックアウトしてコードを利用するというサブコマンドを書きました。

プロダクトごとに設定ファイルを持ち、デプロイ時にその設定ファイルに従って特定のバージョンに変更してからビルドをするというような動き方を実現しています。

 

golangでプロダクトを書いていて困ったこと

先ず、循環参照が出来ない点。golangにはC++のようなヘッダファイルが存在しないので、構造体を定義してパッケージ間で投げ合う時に困る事があります。この時は、ヘッダ用のパッケージを定義し、その配下に本体コードのパッケージを定義する事で回避が出来ました。

次に、型変換を容易にする標準機能が思ったより貧相であること。私は、型変換用のパッケージを別途設計して、全てそれを使いまわすようにしました。実に便利です。

最後に、真のマルチスレッドに対応していない外部パッケージがちらほら存在すること。sql driver周りで嵌りました。泣く泣く、スレッド数を1固定にもどしました。ヘボサーバは1コアだから悔しくなんてないんだからね(グスン

 

golangでプロダクトを書いていて気を付けたこと

先ず、各機能に「状態」を持たせないようにしました。

誰かに呼ばれるのは一期一会。どのように呼ばれようと、同じ値が同じ環境に投入されると、同じ結果が返ってくるように書いていきました。関数的表現のエッセンスを取り入れた結果です。

次に、構造体をなるべく使うようにしました。実に便利です。ポインタを投げ合うの、楽しいです。各メソッドのI/Fにも影響が出づらいので、良いです。

そして、goroutineとchannelを上手く使い、並列化できる処理は並列化しまくりました。

最後は、各処理の独立性を上げた構造を意識していきました。

これぐらいの注意点で、十分動くものが作れます。

 

最後に

goに入ってgoに従う

これですよ。goにはgoの書き方がある。それに従えば何とかなる。

え? これが言いたかっただけだろって? ハハハ

 

goと共にあらんことを。/ May the Golang be with you.

 

技術的なお話をあえて避けて、実際に使った人の視点で書いてみました。

golangでプロダクトを書きたい方、安心してください、怖くないですよ。

ちゃんと書けます。だから、怖がらずに採用しても大丈夫な言語です。

  

明日は Go Advent Calendar 2015 その2 の13日目となります。

13日目の投稿はこちらの方達です。

 

CM

こんなのやってます

kug2.connpass.com

 

ではでは!

ITエンジニアに求められる最低限の素質とは

やあやあ。

夏だから色々ぼやいてみたいと思うよ。

 

ところで、ITエンジニアに求められる最低限の素質って、何だと思いますか?

色々あると思います。よく聞くものとしては

  • コードを書く技術
  • 仕様書を書く技術
  • 算盤をはじく技術
  • 専門特化した知識
  • コミュニケーション力

この辺りですかね。

さて、本当にこれらがITエンジニアに本当に必要な最低限の素質となりえるのでしょうか?

 

コードを書く技術

IT技術者としてお飯<オマンマ>にありつくためには何かしらを作って対価にお金を貰うか、作った何かでお金を生み出す必要がありますね。

となると、コードを書く事で何かを生み出す必要があるのは間違いありません。

かと言って、世のIT技術者が皆コードを書いてお飯にありついているかというと、そうでもありません。

IT業界で悪の代名詞としてよく使われるSIerと言う世界では、コードが書けなくてもプロダクトに携わって大金を得ている人種が少なからずいます。

彼らをIT「技術者」と言うべきかどうか、そもそもそういうお金儲けのスタイルがどうかと言う話もありますが、事実として、コードを書く「技術」がなくても生きていく方法はあるようです。

必要とされるのは「コードを書く『手段』」のようですね。

ですので、一旦最低限の素質としては保留しておきましょう。

 

仕様書を書く技術

コードが書けない彼らの内、その一部は「仕様書」なるものを書いてお飯にありついているようです。この仕様書を元に、コードが書ける人に理想の実現を代行して貰おうという仕組みのようです。では、この仕様書を書く技術があれば最低限の素質を満たしていると言えるのでしょうか?

所で、みなさんはデスマーチと言う単語をご存知でしょうか。デスマーチとは、破綻したプロジェクトの中でメンバの健康や私生活を無視して、命のある限り過酷な労働を強いる状況を指します。

この地獄の所業が起こりうる要因は沢山ありますが、その内の一つとして、「方向性が確定されておらずフラフラとした質の低い仕様書で強引にプロジェクトを進める」と言うものがあります。

この低品質の仕様書が生まれる更なる原因は、仕様書を書く技術に乏しいと言う事では説明できないことがママにあります。よくある話としては

  • お客さんがコロコロと要望を変える
  • お客さん自身が望んでいるものが分かっていない
  • クリエイティブと言う単語を免罪符に行われる無慈悲な仕様変更
  • 政治的な要因で結論ありきで仕様が決まる

まあ、この辺りでしょうか。これらは仕様書を書く以前の問題ですので、仕様書を書く技術だけでは、安定してお飯にありつけないようです。

ですので、こちらも一旦保留としましょう。

 

算盤をはじく技術

コードが書けない彼らの内、「仕様書」も書かずにお飯にありついている人もいます。それは、算盤をはじいている人です。つまり、お財布を握っている人ですね。

プロジェクトの中では、誰かに働いて貰う為には、それ相応のおちんぎんを用意しないといけません。SIerの世界では、それを「人月」という単位で扱う事が多いです。

 

とある要件を受託し、そのプロダクトを納品する為に、4人で6ヵ月掛かるとしましょう。すると、このプロダクトは 4 x 6 = 24人月必要な案件であると表現されます。

仮に、1人月のランニングコストが社内で70万掛かるとしましょう。これを粗利30%と仮定して、100万/人月で契約すると、24人月で2400万円の案件となります。

 

こういうことを考えて、お金の出入りを管理する人も、ITエンジニアとしてご飯を食べているわけですね。

 

さて、先ほどの例題に戻りましょう。

この2400万の案件で現時点では粗利が30%なので720万なわけですが、良くある話としては、利益を720万ではなく1000万以上に何とかしろと言われることがママにあるわけですね。ここで算盤をはじく人は以下のようなことを考えます。

 

算盤をはじく人「今の予算はこうだ」

 4(人) x 6(ヵ月) = 24(人月)

 24(人月) x 100万 = 2400万

算盤をはじく人「で、以下を達成したい」

 2400万から1000万以上の利益 => 実働1400万でやりくりすれば良い

算盤をはじく人「予算から考え直そう……」

 実働1400万 => 1400万 / 70万 => 20人月

算盤をはじく人「20人月で回せば何とかなる!」

 5(人) x 4(ヵ月) = 20 (人月)

 4ヵ月あれば、土日全部使えば+1月分くらい時間は生まれる

 残業代はかかるが、4人月浮くからそれを更に別案件に売ればいい

算盤をはじく人「ふはははは、完璧じゃないか!」

 

まあ、この後どうなるのかはお察しですね。

このような事ばかりしていると、実際に手を動かしてくれる人はその場を去っていきます。このような焼き畑農業ばかりしていくと最後は自分にも火を放つことになるので、安定してお飯にありつけないですね。

ですので、こちらも一旦保留としましょう。

 

専門特化した知識

「我々には、今まで培ってきた知識・経験がある」

よく聞くワードです。つまり、今までの案件に特化していると言う事ですね。

さて、将来の案件もまた、過去の実績でどうにかなるのでしょうか。

いや、確かに同じような案件は続くかもしれないのでそれらに関しては太刀打ちできるでしょうが、それ以外の依頼では役に立たなさそうですね。

 

もう少し具体的な専門特化を考えてみましょう。

例えば「金融系システムに特化した知識」があったとして、それが売りだと言っている集団に「スマートフォンを使った新しい案件」が飛び込んでくるでしょうか?

多分飛び込んでこないでしょうね。

 

なら、「スマートフォンを使ったソリューションに特化した知識」があると豪語する集団があったとして、将来生まれてくるであろう全く異なる異質な要件が、彼らの元に降り注いでくるかと言うと、きっとその時には回ってこないでしょうね。

 

「我々は○○に特化しています。これ以外は認めません」という生き方はロックですし、切れ味の良い刃物になるのでしょうが、その刀だけで戦い続ける事は出来ません。

ですので、こちらも一旦保留としましょう。

 

コミュニケーション力

新卒採用市場で最も重視されているという噂の能力ですね。

この謎の力、正体は「自分の意見や気持ちを第三者に伝える力」と定義されています。

はて、面接で自己PR出来てる時点である一定水準以上の能力があるような気がしますが、これだけで本当にお飯にありつけるのでしょうか。

実に謎です。無いよりはあった方が良いですが、別に胸張って威張るような技術ではないんでしょうね。となると、こちらも一旦保留としましょう。

 

本当に必要な素質って何?

なんだろうね。

ここからは私の解釈ですが、ITエンジニアに必要な素質は以下のようなものだと思っています。

  • 怠惰
  • 短気
  • 他人に教えを乞う能力
  • 変わり続ける能力

 

怠惰

「怠惰」は原動力です。ITエンジニアは怠惰であるべきです。

楽をする為に苦労を厭わない奇人であるべきです。

その苦労の末に楽を達成し怠惰を実現した時に快楽を覚える変態であると、尚良いです。

 

短気

「短気」は柔軟性です。ITエンジニアは一つの事だけに囚われず、ダメだと思ったら別のアプローチからも攻めるべきです。

鳴かぬ鳥を鳴くまで待つのはITエンジニアではありません。代わりに鳴くか別のモノに鳴かせるくらいの気変わりの早さがあるべきです。

 

他人に教えを乞う能力

出来ないのであれば、出来る人に頭を下げて教えを乞う。

コミュニケーション力とか言ってる人が真に求めているのはきっとこっち。

「出来ない自分」と向き合って、「教えて下さい」と言える人は、きっと強い。

その本質は「貪欲」。知る為なら、「出来ない自分」と向き合う「覚悟」がそこにはある。

 

変わり続ける能力

最初に挙げた5つの技術や能力たちは、一昔前にあちこちで見た条件でした。

でも、実際にはそれでは上手くいかないことが分かっている。

巷でよく見る、「将来なくなる職業ランキング」に名を連ねる「ITエンジニア」という仕事の在り方は、変わる事を拒否し続けた将来の姿であるともいえる。

実際、部分的にITエンジニアの仕事はなくなりつつある。

その一方で、新しい領域のITエンジニアの仕事が生まれつつある。

ITと言う領域は、あらゆる領域と共に歩み、変化し続けていく。

その変化を恐れず、常に変わり続ける事が出来れば、お飯にありつけ続ける事は出来ると思う。

 

また、これらの私が考える素質は、IT業界に限定された話ではないと思っている。

きっと、何処で働くにしても、これらは必要な事だと、私は考える。

Apple「お前らはApple Watchで時計アプリ作るの禁止な」

やあやあ。

色々物議をかもすApple Watch。

そんなApple WatchにAppleからの鬼裁きが下されました。

 

App Store Review Guidelines - Apple Developer

10. User interface
 10.7 Watch Apps whose primary function is telling time will be rejected

 

どうやら、時計アプリは許さないよと仰ってますね。

ううむ。Apple Watchだぜ? 時計だぜ?

coolなUIを持ったイカレた時計アプリが出来上がる可能性だってあったのに、なんだかなあ。

 

既にいくつか時計アプリが出てたような気がしましたが、この大裁き、どう決着をするのでしょうか?

 

ではでは。

Raspberry Pi 2に Windows 10がやってきた、IoTが捗るな!

やあやあ。

遂にRaspberry Pi 2に Windows 10がやってきましたよ。

 

Windows IoT - Get Started

 ↓

Windows IoT - Set up your Raspberry Pi 2

 ↓

Windows IoT - Setup your PC for Raspberry Pi 2

 ↓

Windows IoT - Develop

 

いや、もう、これで色々と遊べてしまいますね。

Raspberry Pi 2以外にも遊べるボードがあるようなので、そっちを持ってる人はそっちで遊んでも良いかも知れませんね。

 

 

 ではでは。

マイクロソフト( Microsoft )が一晩で世界線を書き換えた話

やあやあ。

タイムリーな話だけど、マイクロソフト一晩でやってくれましたね。

 

www.buildwindows.com

 

channel9.msdn.com

 

Build 2015は MSのイベントで開発者向けに行っているものです。

そう、このエントリーを書いている間も開催中なんですね。

 

そろそろ始まるよという話は来ていたのですが、あんまりピンと来ずに一晩寝ていました。すると、朝目が覚めたら世界線が変わっていたんですね。

 

いつの間に、ダイバージェンス 1% の向こう側へ?

 

どう変わった?

開発環境の他プラットフォーム展開

Windowsで開発用のエディタと言えばVisual Studioが最初に名前が上がります。誰が何と言おうと、こいつは最強。当然闇も深いが、メリットの方がデカいです。

こいつのコアな機能を取り出して再構成されたと言っても過言ではないエディタとして、プラットフォームの縛りがない状態で公開されました。主にGit、IntelliSense、reference、debugger機能が搭載されており、エディタであると言われていますが、IDEを名乗れるくらいの実装がなされています。

https://code.visualstudio.com/

 

中身は「Electron + Monaco」だそうですが、最近のトレンドの先端を行ってる感じですね。

blog.shibayan.jp

 

on browserなので、どうやら[F12]押下すると開発者ツールが開きます。

そこから眺めるとnative.main.cssにスタイルが記述されているようなので、ここをhackすると、自分だけのオリジナルエディタにお手軽チューンできるのも熱いですね。

 

また、Macでこれを使うとUnityが日本語環境で書けるようになるとかなんとか。補完も恐ろしく速いらしいので。救世主となりえるのか?

 

Visual StudioObjective-Cコンパイル可能になった

知って直ぐに出た言葉が、「……正気か?」でした。

どうやら正気のようです。

実際には、Android用のアプリやiPhone用のアプリをWindows上に持ってきて、チョロッと直してWindows用にbuild出来る変態SDKの提供だと(語弊をはらみつつ)理解すればよいようです。

実際には、その通りではないですが、まあ夢がある話ですよね。うん。

Androidの方はほぼストレートで持ってこれるそうなので、Android AppとWin Appの同時開発はWindowsで、iOSMacでとなっていくんですかね。MacユーザーはbootcampにWindowsを入れるんでしょうけどね。

 

この流れ、Windows Phoneがnew Windows ( Windows 10 )ベースで出てきて、既存のプラットフォームを食い漁りに来るという宣戦布告なのだろうか?

Huge news: Windows 10 can run reworked Android and iOS apps | The Verge

 

 

さようならInternet Explorer ( IE )

IEと別れを告げる日が来たようです。つい最近、Trident engineに泣かされたばかりの私ですが、EdgeHTML engineを搭載したMicrosoft Edge ( 開発コード:Spartan )がWindows 10では実装されるようです。今後は、IEではなくMEということですね?

 

で、このEdge、FirefoxChromeの良い所を多分に吸収し、果てにはそれらプラットフォームの拡張機能をちょっと直すだけで取り込めるようにしようとしているようです。

Microsoft's Edge browser can steal Chrome and Firefox extensions | The Verge

 

先のAndroid / iOS Appの取り込みと続き、なりふり構わぬ本気のMSが見え隠れしていますね。

 

www.youtube.com

 

現実拡張でWindows 10が世界に溢れ出す

www.microsoft.com

Windows 10 apps in HoloLens look amazing and completely ridiculous | The Verge

 

 

いやもう、何が何やらですね。

一気にここまで来るとか、恐ろしい話です。

今までのヘッドマウントディスプレイとは全く異なる何かですね、これは。

 


 

 MSは今までのOSを作っている会社とは違う世界へ踏み出したようです。

前からそういう事に投資をしている会社ではありましたが、ここまで大きく出たのはここ最近ではなかったんじゃないですかね。

 

賛否両論あると思いますが、私は好意的に受け止めたいと思います。

 

そういえば、build 2015ってまだ開催中なんですよね。明日は何があるんだろうか。

関数型とオブジェクト指向の話

やあやあ。

この記事はポエムだから肩の力を抜いて欲しい。

 

最近話題の関数型

最近巷で関数型ポエムの話をよく聞いたね。

あのポエムが良いか悪いかの論争はこの場は論じないでおこうと思うけど、そもそも関数型ってなんなんだろうね。

 

関数型プログラミングについて書いてある本を読むと、先ず最初に目に飛び込んでくるのが、「数学でいう『関数』と同様に、一意の値を与えると、常に同じ答えが返ってくる、副作用がないもの」という表現である。

 

語り始めると宗教論争が生じるし、この表現でもまだ突っ込みどころはあると思うので深入りはしまいと考えているが、要はそういう表現型ばかりを使ってプログラミングを書いていくと、副作用を排して手堅いコードになっていきますよねと言う事らしいのだ。

 

関数型の発想が与えるオブジェクト指向への影響

関数型は、ある種の思想であると、私はここ数年捉えるようにしている。

これも色々宗教論争を呼びそうではあるが、聖書に書かれた教えの解釈は宗派によりけりなのである程度は目をつぶって頂きたい。

 

オブジェクト指向でプログラミングを書いているとよく陥るのが、プログラムが実行中に「状態」を持ってしまい、それによって「タイミング」が生じ、時によって「結果が異なる」挙動を示す場合がある。

これを関数型の教義では「副作用がある」と表現するらしいのだが、そんな表現を知らなくともよくある経験だと思う。そこでよく使う方法が、条件分けや例外処理である。私はこれらを、「副作用を分類している」のだと解釈している。

 

私は今までの仕事柄、副作用を生む処理を記述すると、不具合によっては私の睡眠時間や空実が失われていくという「副作用」を齎すと言う事を知っていたので、関数型という思想に触れる前から、関数的に処理を書こうと試行錯誤をしていた経験がある。

 

ある日、Scalaと出会い、その後Haskellと出会った。

正直に告白すると、そのどちらの言語も満足に書ける自信はないのだが、それらの一片に触れ、考え方を覗き見たという経験は非常に役に立ったと思っている。

 

関数的に書くという意識を持つだけで、純粋な関数言語ではない他のオブジェクト指向言語においても、1メソッドを起こすだけにしてもよく考えるようになった。

真に副作用を排する事は極めて困難であっても、「副作用はこの場合何を齎すのだろうか」と考えるだけでも、やはり関数型言語に学ぶところは多いのである。

 

平々凡 々なオブジェクト指向エンジニアが
関数型とどのように向かい合うべきか

自身の業務や現実と向き合ったうえで、学んだ分だけ可能な範囲で取り入れていけばよい「教義」と捉えると幸せになれるんじゃないかなと思います。

関数型の信徒になって、その世界に閉じこもりたいと思うようになれば、そういう人はそれを専門に使っている世界へ進むと幸せになると思います。

ファン程度であれば、教義に倣う程度でにわか関数型エッセンシャル使いを名乗ると幸せなんじゃないのかな。

 

真剣に学ぼうと思うのであれば、先人の教義に従い、古の専門書から手を伸ばすのが吉であると、私は思います。

 

ではでは。

 

CSSでセンター寄せはどう書き分けるべきか

やあやあ。

HTML5ではcenterタグが非推奨になっているらしいね。

と言う事で、要素の中央寄せをCSSでする方法についてのメモを残しておくよ。

 

  • marginプロパティ
    • margin:auto
    • margin-left:auto + margin-right:auto
  • text-alignプロパティ
    • text-align:center

実際は上記のようなプロパティをCSSから指定することになる。

margin系とtext-align系の大きな違いは何であろうか。

 

margin系で中央寄せをする場合

margin系は、指定されたオブジェクトを寄せます。

その場合、オブジェクトの中身(ここでは文字列)は左詰めのままの解釈を受ける。

 

<style>
  #margin_test{
    width: 200px;
    margin: auto;
    background-color: #808080;
  }
</style>
<div id="margin_test">てすとてすと</div>

 

てすとてすと

 

<style>
  #margin-left_test{
    width: 200px;
    margin-left: auto;
    background-color: #808080;
  }
</style>
<div id="margin-left_test">てすとてすと</div>

 

てすとてすと

 

<style>
  #margin-right_test{
    width: 200px;
    margin-right: auto;
    background-color: #808080;
  }
</style>
<div id="margin-right_test">てすとてすと</div>

 

てすとてすと

 

<style>
  #margin_LRmix_test{
    width: 200px;
    margin-right: auto;
    margin-left: auto;
    background-color: #808080;
  }
</style>
<div id="margin_LRmix_test">てすとてすと</div>

 

てすとてすと

 

text-align系で中央寄せをする場合 

text-align系で中央寄せをする場合、オブジェクトはそのオブジェクトの指定属性のまま、その中身(ここでは文字列)が中央寄せの解釈を受ける。

<style>
  #text-align_test{
    width: 200px;
    text-align: center;
    background-color: #808080;
  }
</style>
  
<div id="text-align_test ">てすとてすと</div>

 

てすとてすと

 

どっちを使うべきか

中央寄せしたいモノで決めよう

 

但し、margin-leftとmargin-rightの合わせ技で中央揃えをする場合、古いIEでは適切に解釈されない可能性がある事を知っていないと罠に嵌る。