CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方インクリメンタルに新しい技術を取り入れる方法 [/karte-blocks-incremental-development/]では、VueからReactへ段階的に移行していったという話を紹介していました。 このReactの採用を決定してから大きな論点となったのは、ReactでCSS(スタイル)をどのように書くかについてです。 Reactのスタイリング方法には、デファクトと言えるものはありません。
「0→1」フェーズにおける技術的負債との向き合い方 - jmblog.jp
以前から「スタートアップのなかで『技術的負債』というものをどう扱うべきなのか」というテーマに対して関心が高かったのだが、今年の6月から「0→1」の新規事業に関わるようになって、自分の中でなんとなく考えがまとまりそうなので、雑に吐き出してみる。最近、社内でも「技術的負債」が話題にあがることが多く、その中で同僚のエンジニアからあがった意見も参考にしている。 そもそも技術的負債とは @t_wada さんの次の記事に答えが書いてある。 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ 個人的には次のように解釈した。 「手を抜いた雑なコード」は技術的負債とは呼ばない。それはただの低品質なコードである 仮説検証や経験からさまざまな学びを得ることは正義 そこで得た「学び」と「現状のソフトウェア」とのギャップを「技術的負債」と呼ぶ このよう
セルフマネジメント・テクノロジー「Za」とは
〔最終更新日：2016年10月27日〕 Zaは「全従業員がプロフェッショナルな黒字社員」という強い企業を実現するためのセルフマネジメント・テクノロジーです。 組織内に「市場」の原理を導入し、従業員一人ひとりの損益を可視化し、自営業者のような自助的マインド、つまり個々人の「自営力」を喚起します。 そもそもZaが生まれたきっかけは、社員が次々に辞めてしまうというマネジメント上の危機でした。そのとき私は経営者として絶望的な気分で、「何が悪かったのか」「どうすればよかったのか」と自分を責めながら、マネジメントの本をたくさん読み漁っていました。そのとき、ふと思い出したのです。私は「人から管理されたくもなければ、人を管理したくもない」と思って自営業者になったのでした。 そして気付きました。私に必要なのは「経営者として組織をうまくマネジメントできるようになること」ではなく、「管理しなくても会社が回る仕組
技術選択とアーキテクトの役割
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。
大学のレポート提出で一工夫したらコピペが皆無になったという話
レポートを「特許同様に先願制とする。つまり意図せずとも類似内容だった場合後に提出された方を減点する」と呪文を唱えたら、コピペが皆無となった上に〆切よりだいぶ早く集まった — Masahiko Inami (@drinami) 2009, 12月 22 当方が学生時代もレポートの類や試験の筆記問題などは(持ち込みがOKな場合も多々あるので)、OBなどが持つ過去問を頼りにそのまま写したり、ほぼトレースする所業が多数行われていた。中には歴代の先輩たちが使いまわしする、伝説のレポートなんてのもあり、高値で取引されたってのも記憶にある。何度となくコピーされたせいで、文字が随分かすれていたり、ね。まぁ、問題を出す教授側も新しい問題の設定が面倒くさいのか、毎年同じものしか出さないのも一因なんだけど。 今ではインターネットが普及しているので大学生界隈では情報の共有ももっとスマートになってるんだろうけど、同
学生に考えさせる授業
矛盾の止揚の教育（福耳さん） 学生に、Ａという仮説を教える。そして然る後に、Ａと矛盾する仮説Ｂを提示する。そして教えるこちらからはＡＢ間の矛盾は解決しない。学生自身に矛盾について悩ませる。 その結果、そうとうちゃんと考えてこそ、ＡＢそれぞれをふまえて、両者を止揚した仮説Ｃに学生自身の手でたどりつく。それをしてこそ、本当に自分の頭で考えて、自分の頭の中にその成果が残り、洞察力という力の存在を認識できる。 そういう講義をせんとあかん、と思ったのは、いまの学生、「決まった正解を教わるのが大学の講義」と勘違いしているからである。あーこどもっぽくっていや。そんなの、チャート式でも読んどいてくれ。 僕なんぞは、考え方ではなくって、他人が勝手に決めた正解を学んで、なにが面白いのかなんて思いますがねえ。 なかなかうまくいかないというか、結局のところ、学生が演技力を駆使するだけの結果となりそう。 というのは
大野左紀子さんをコピペレポート問題から解放する（かもしれない）授業案
レポートコピペ問題の問題（大野左紀子さん） しかしいろいろ参照したとしても、最終的には「自分で考えて意見をまとめる」という基本的なことが教育できない、その重要性すら叩き込めないとしたら、単に教育者や教育システムの問題だけなのだろうか？という疑問は湧く。それは、「自分で考えて意見をまとめる」ことが本当に大切なことだとは、世間では思われていないということの現れではないか。 自分で考えることが大切なのではなく、そこはショートカットして自分で考えたかのように振る舞えることが（処世術として）大切、というふうになっているのではないか。それどころか、もしそれが他人の意見だとしても、少なくとも自分よりは頭が良さそうな人の意見に右に倣えで、何が悪いのかと。世の中そんなものではないかと。自分の意見なんかいったいどこで求められるんだ‥‥。 いやいや、堂々と「学生に『考えさせる』なんてくだらない」といっている（下
講座設計のイロハ
1． 数年前、ふと気になって、夏休みの宿題について WWW にどのような情報があるのか、調べてみました。出てくるのはたいてい、宿題に取り組む人のための情報でした。 たまに親視点の情報もありましたが、基本的に「宿題に取り組むのは子どもであって私じゃない」というスタンス。子どもが宿題をサボるのは自分が至らないからだ、と考える親はほとんどいないらしい。なるほど、「勉強しなさい」と他人事のようにいうばっかりなわけです。 私が「夏休みの宿題」という小文集を書いたのは、こうした状況への抗議でもありました。宿題は家族で取り組むもの、子どもだけに「やらせる」ものじゃない。だから、保護者は子ども以上に、宿題にきちんと取り組まねばならない。そんな主張が、検索上位にひとつくらい顔を出してもいいはず……。 今日、「夏休みの宿題」と検索してみると、宿題の指導がたいへんというお母さんの質問が上位に出ていました。私の解
キミの設計に「トレーサビリティ」はあるか ― ＠IT情報マネジメント
システム開発の流れを俯瞰（ふかん）する 1.1 「ビジネス要求」から「実装・テスト」までステップは5段階 システム開発の工程は5つに分けることができます。すなわち、 ビジネス要求（の分析） システム要求（の分析） 機能（の設計） メソッド（の設計） 実装・テスト（の実施） です（図1）。 「ビジネス要求（の分析）」から「機能（の設計）」までを開発工程の前半とします。前半段階では、構築すべきシステムに対するビジネス・サイドの要求を明らかにします。つまり、業務を見える化（モデル化）し、誰にでもわかる形に仕立てます。 「メソッド（の設計）」から「実装・テスト（の実施）」までを開発工程の後半とします。後半段階では主に、システムに対するビジネス要求を実現するための機能（メソッド）を設計します。設計作業が終了すると、実装、テストを行い、機能が正しく実装されているか、ビジネス要求が満たされているかを検証
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う