タグ

2013年2月24日のブックマーク (4件)

  • +BLOG

    +BLOG ヤバイ!AMAZONプライムデーでこれ買った!ベスト1 2023/7/12 地元民が選ぶ名古屋グルメおすすめ12選 2022/7/22 モンブランクレープがべられる『IVY’s GELATO&Coffee』 2022/7/8 2022/7/11 洗車後のコメダ新作『ミルクロネージュ』が身体に染みた 2022/7/3 真夏日PM3:00地獄のジムニー洗車 2022/7/2 『ブルーボトルコーヒー』でワッフルコーヒータイム 2022/7/1 灼熱地獄でべるレッドチリスモーキーワッパー 2022/6/30 毎年恒例のすき家でニンニク祭してきた 2022/6/29 2022/6/30 小袋ナッツどれがいいんだ問題を解決する 2022/6/28 買うべき名品!ドンキの『ナッツ&デザート』 2022/6/27 +BLOGは名古屋のフリーランス個人ブログです! 人気記事 ヤバイ!AMAZ

    +BLOG
  • 知ってるとちょっと役に立つCSSのTipsまとめ

    ちょっとのつもりでCSSサンプルコードチマチマ書いて記事化してたら10件以上たまってました。 基的に私はWeb屋さんではないので結構いい加減なコーディングしてたりもしますが、WEBサイト制作ではよく使いそうなプロパティについて使い方を説明してますのでなにかと参考にしていただければ。 こういった記事は基的に「知らない人向け」に書いて(だからこそ役に立つ)ますので、不必要な部分はあえて端折ったりしている一方で必要なところはやや冗長と思われても出来るだけ詳しく書いてるつもりです。あくまで初学者向け。 というわけで当ブログCSSネタまとめ2013年2月版ということで。 1.長文テキストを段組CSSで文書の段組表現を行うcolumnプロパティの使い方 一連の長~い文章を1つのボックス内で段組するにはどうすればよいでしょうか?というお話。columnは地味というかあんまり知られてないプロパティっぽ

    知ってるとちょっと役に立つCSSのTipsまとめ
  • 内部仕様書はロジックを書くものではない

    もっとも「ロジック」というのも程度問題なのだけど、 少なくともプログラム言語で記述するレベルでのロジックを書くというものではありません。 いや、特定の企業ではそういう書類を(しかもプログラム前に!)書かせるように強要してきたりするけども。 参考:IEEE830-1998におけるソフトウェア仕様書(内部)の書き方 そもそも業界ではさも当然のように「外部仕様書」とか「内部仕様書」という言葉を使っていたりしますが、 あまりきっちりした定義はありません。上記でも「内部仕様書」という定義ではないわけですし。 各社の文化で独自に解釈されているのが実情ですかね。 ニュアンスとして外部/内部というのはI/O境界面からの外部/内部といった感じ。 他のチーム(別会社だったりする)とかとやり取りするために、この機能は外から見たらこんな感じ、というのが外部仕様で、 中はこう言う風に作るっていうのが内部仕様とされま

    Koozz
    Koozz 2013/02/24
    良いものを作るためにドキュメントは必要かもしれないがロジックまで書くのはバカだ
  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

    昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
    Koozz
    Koozz 2013/02/24
    すごく共感している。今大手Slerで仕事しているけど、本当にこの流れでワロタ