「永続化」を含む日記 RSS

はてなキーワード: 永続化とは

2017-11-05

Webフレームワーク選定の悩み

Webアプリを作るとき何を基準にしてプログラム言語Webフレームワークミドルウェアを選定していますか?

RailsCoC:convention over configuration)以外の手法活用して、開発を高速化するにはどうすれば良いでしょうか?

 

希望条件

  1. 素早いプロトタイピングscaffold機能など
  2. テストコスト削減:関数型プログラミングモジュール手法
  3. 性能:コンパイル型の言語

…こういう条件を備えていれば良いかな?

 

フロントエンド

  1. JSGUI作成Vue.js等のSPAフレームワーク

 

バックエンド

  1. データ永続化ストレージCRUD機能を用意できれば何でも良い?

 

試作

  1. Railsプロトタイプを作りデザインスプリント実践

 

本番

  1. 形が決まったらGolangGCPで作り直して本番投入

プロトタイプを作り直す手間を省きたい。プロトタイプと本番を同じツールで作りたい。)

 

サーバーAWSバックエンドElixir/Phoenixフロントエンド:Elmという組合せはあまり盛り上がっていないようなので、Rails代替手段は何が良いのか?気になります

2017-06-08

http://anond.hatelabo.jp/20170608112044

「十何人」を変換履歴学習させてしまったのだろう

通は変換による学習をOFFにする

少なくともファイルに保存して永続化する設定をOFFにする(起動中覚えてるようにするかどうかは好みで)

たとえばこの文章で「変換」という言葉が出てくるがこれは毎回「返還→変換」の変換をしている

一見めんどくさいが「ヘンカンという言葉は 1.返還 2.変換 である」と覚えてしまえば変換キー1押し2押しで確定できる

2017-06-07

http://anond.hatelabo.jp/20170607131311

>つまり増田が言いたいのは、お金で勝ったのはロスチャイルドのみ、あとは全員負けってこと?

そうだよ

ロスチャイルド家が生まれときからヘビー級ボクサーの体型なのに

下々がコロポックルで汗水たらしてボクササイズやって粋がってるのが資本主義経済

ちなみにロスチャイルドならいくらでも筋肉量増やせるしコロポックルに減量を強制させれます

 

>それとも、そんなことはないので世の中お金じゃないぞっていいたいわけか?

ロスチャイルド家以外はお金で上位に食い込めないんだから途中でお金を追いかけるのをやめてスピリチュアルに逃げる

莫大な富を持っている個人資産家が寿命を前にして愛とか慈善活動に目覚めるのは

それをシステム化して永続化できないことに無意識に気づくから

よく「おいさき短いのに金持ってても意味が無い」っていうけど

それを解決して永遠に子々孫々が裕福なままにしたのがロスチャイルド家

スターからゴールまで金持ち

からちゃんと答えはあるけど1代では到底無理だし

先にロスチャイルドが居座ってるのに個人いくらシャカリキになっても勝てるわけがない

2017-01-17

自分の書いたコード自分の作ったプロダクトのどこに価値を見出せばいいのかいまだにわからずにいる。

学生時代簡単アプリケーションを作ったり、フロントエンドを好んで勉強していたから、就職して初めて携わることになったサーバサイドの開発ではこれまでの画面のような目に見える成果物がないことに戸惑った。処理が進むたびに書き込まれる膨大なログDB永続化されたレコードたち、確かなものはそのくらいで、自分が作ったものがここにあるというイメージは全く沸かなかった。

プロダクトを利用してくれるユーザは違う会社のその先にいる遠くの誰か、あるいはいるのかどうかもわからない程度の売れ行き、賞賛どころか不満の声すらこちらには届かない。業務システムからこんなものを作っているのだとドヤ顔して友人に見せびらかすこともできない。案件経験するたびにタスクをこなせる量が増えたり、人に聞かなくてもある程度自力設計してコードを書けるようになったり、そういう実感は多少なりともあるのだけれど、それだって自分から見た自分評価しかない。良い設計ができてバグのない実装ができたところで給料が上がるわけでもなく、お客様から褒められることもない。あるとしても同僚や先輩たちからこいつは多少コードが書ける人間なのだと、見切りをつけられない程度のこと。綺麗なコードを書いても年功序列の弊社では給料は上がらないし、数字で示すことができないものにお偉方は報酬をよこさない。

うちのプロダクトは特別大きな負荷がかかる処理でなければさして性能は重視されないし、設計コードも明らかにまずい作りをしていなければレビューは通る。自分コードは最低限リリースできる程度の品質であることはマージされればわかるけれど、さてこれは良いのか、それとも悪いのか。自分では判断がつかない。あるいはもっと良い作り方があるのか。答え合わせの機会がないまま淡々リリース日だけが迫ってくる。いつのまにか新しい案件下りてきていて、日々はめまぐるしく過ぎていく。

また今日も、いかにも売れなさそうなサービスひとつリリースされた。自分なりに綺麗に設計できたAPIだけれども、API設計が綺麗だからってユーザから褒められるわけでもないし、作ってる人間からしても売れなさそうなだと思うだけあって、そもそもの話、このAPIが実行される予定は未定。

最近自分が初めて開発に携わったサービスのことを思い出す。リリースから1年、いまだにユーザがつかないまま、初めての申込APIが呼び出される日を待ち続けている。

自分が生んだプロダクトの価値を認めてくれる誰かの声を、私も待ち望み続けている。

2016-01-21

http://anond.hatelabo.jp/20160121144611

意識記憶永続化されていないのだから、糊付けされたのか「その時々によって違うもの」なのかは分からんやろ。

2015-12-22

http://anond.hatelabo.jp/20151222093549

それだと根本的な元凶である日本の家制度は温存されたままだから、おそらく彼ら/彼女らは納得はしないだろう

彼ら/彼女らの目的日本の家制度否定さらに踏み込めば戸籍制度消滅から、そういう解決策はむしろ制度永続化に繋がりかねない

まあ、それ故に現実的折衷案が採用出来ず、社会的にも関心が持たれにくいという面もあるんだけど

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-06-04

http://anond.hatelabo.jp/20140604151658

あいDB構造データを保持する、C#のクラス

人事画面使えるかどうかフラグは、bool?で定義すべきだって言ってるの。

boolにしたら、使えるか使えないかしか入らないから、未定義永続化できないでしょ?

で、取得した結果、例えば画面を開くメッセージ

if(人事画面使えるかどうかフラグ == true)

「使えるよ! 開くよ!」

else if(人事画面使えるかどうかフラグ == false)

権限がないから開けないよ!」

else if(人事画面使えるかどうかフラグ == null)

ユーザーグループが未定義だよ!」

とこうしたい場合に使うって言ってる。

http://anond.hatelabo.jp/20140604150948

引っ張るときにnullになることがあるのは良いとして、nullableで持つってどういうこった? 永続化されるデータがnullableなのか?

そも、C#やなくてもJavaとかでもプリミティブ型以外は参照しか持たんからデフォルトでnullableや。

わざわざnullableにしなきゃいけなくなるパターンってなんや

2013-12-08

スタイルを一貫させなさい

 日本人はとかくファッション一貫性に欠けると叫ばれる。確かに日本文化和洋折衷、何でもありの文化であるな。例えば、仏教国の1つでありながら、年末になると突然「ジングルベ~ル」などとバカ騒ぎしだすwそしてどういうわけか年明けには神社初詣。おめでてーな正月

 で、世界的に見れば一貫性がない、主義主張の曖昧なことは「ダサい」「気持ち悪い」とみなされることは知っておいて損はない。これは単なる主観ではなく明確な根拠がある。日本のような画一社会(個人単位では一貫性に欠けるくせに社会単位ではある意味一貫性がある)では想像つきにくいだろうが、欧米は基本的に多民族社会であって、国内民族間対立や隣国との民族間対立が深刻な問題であるから、こと人間関係おいても相手がどんな人間か知ることが差し迫った課題になるわけよ。だから、「はじめまして」の次には「あなた宗教は何ですか?」などといった話題がポンポン出てくるのが常なわけ。日本じゃ「ご趣味は?」などと言えば「お見合いかよ」と思われる始末で、相手のことはある程度「お察し」するのがお約束になってゐるが、海外ほとんどの国ではまず初対面の人には最初に相手の思想区分を分類する作業がお約束なわけだね。そんなわけだから日本人のようなスタイルのよく分からない謎タイプキャラというのは、文字通り「えたいのしれない」人間として扱われるのよ。だから、もし貴方が日本人でこれから国際社会活躍したいなら、まずスタイルを一貫させること、そこから始まると言って良い。ビジネスで信頼を勝ち得るには、もちろん人間性やコミュ力も大切だが、実はそれと同じくらい明確なスタイルを持っていることが大事なんだ。そもそも日本文化とは何なのか?自分はどんな人間なのか?そこから考えてみたらどうだろう?

 それとは別に一貫性を持つことは実を言えばとても気持ちの良い生き方だということも知っておきたい。一貫性がないとは裏を返せば裏表があるということで、表の時に裏が気になり裏の時に表が気になるという状態だ。遊んでる時に仕事が気になり、仕事の時に遊びが気になる。そんなんではダメだろう?いくら仕事ができてもダメ。遊びがいくら楽しくてもダメ仕事も遊び、遊びも仕事と思えて初めて一貫し、そこで初めて心の平安が訪れる。断っておくが、ここまで来ると日本人だけの問題ではなく、全人類の存亡がかかった問題とさえ言えるものだ。この先人類が生き残るには、スタイル一貫性いかんにかかっていると言っても過言ではない。というのも、今の情報社会おいて「気になる」ことが大きな文明衰退の原動力になっているからだ。最近スマホでソシャゲをやっている人をよく見かける。ソシャゲも一貫したスタイルの一部に組み込まれているなら良いが、多くの人はそうではない。「気になる」から続けてるのだ。古くは「mixi中毒」と言われた社会現象に始まる。本人は「遊び」「気分転換」でやってると主張するがその内実は全くことなる。「気になって仕方ない」のだ。GMailのinboxも気になって仕方ない。ケータイメールも気になって仕方ない。神経症現代人共通の病と言っても過言ではなかろう。心の整理が我々人類の急務なのである。1つのことに落ち着いて集中できず絶えず気になることに囲まれた生活が本当に健全と言えるのか。それを今こそ問い直すべき時期に来ている。

 問題を叫び立てるだけではあまり意味がない。ここに解決策を提案しよう。その前に一貫性定義を確認しておこう。勘違いされがちなのだが、一貫性とは無駄ものを削って1つに絞ることではない。一貫性一貫性と繰り返していると、近視眼的なイメージを持つ人もいるようだから、このことは強調しておく。例えば、目標を1つ決めてそれに自分の全てを費やす人生はいかにもアメリカ成功哲学で受け入れられないと拒絶反応を示す人がいるが、そういう話ではないんだな。それはむしろ最初から一貫性を諦めて、一貫性から外れた「気になる」ことがあっても気にすまいと頑張る行為から一貫性とはある意味真逆とさえいえる。「仕事一筋」「柔道一直線」と言えば聞えはいいが、それは微粒子レベルシビア見方をすれば一貫性とは言えない。なぜなら簡単なことで、厳密には仕事のことだけ、柔道のことだけ考えていては、生きていけないから。もう分かっただろう。そんなまがいもの一貫性を目指してはならない。一貫性というのは、既にあるものに「統合性」をもたせることでなくてはならない。

 であるから、解決策もおのずと見えてくる。統合的な目的を持てばよいのだ。目標ではなく目的。低いレベルでは相容れないものどうしを高いレベル統合させるにはそれしかない。ウメハラが著書において「目標はもたない」と書いている。目標をもたないのに何故彼のスタイルは一貫しているのか?それは高いレベル目的があるからである。彼の場合、日々の成長がそれにあたる。とても簡単なことにみえる。だが、考えれば考えるほどやればやるほどこれが簡単ではないのが分かってくる。先ほど一貫性定義を確認したのはそのためだ。ただ単に、成長のために全ての人生をなげうつ、持てるエネルギーの全てを投入するだけではダメ。それだけでも難しいじゃないかと思うかもしれないが、それだけ出来ても1%も出来たことにはならないという話である無駄努力乙というやつで、まるで方向性が違う。早い話、今日から成長という統合的な目的のために生きてウメハラになるぞと思った時点で、君は自分の多くの「無駄」を捨てるだろう。それは自分を削って見せかけの一貫性を作っているだけで、実際一貫性でもなんでもない。ハリボテのエレジーである。ハリボテだから必ずしわ寄せがくる。今日からソシャゲをやらないと決めた所で気になるものは気になるのである。ソシャゲ自体は気にならなくても形を変えて繰り返し噴出してくる。だから我々は「捨てずに」統合する必要がある。捨てて統合出来ましたと言ったってそんなの出来て当たり前であって統合でもなんでもない。

 さらにもう一点、オレの目的毎日の成長だといくら声高に主張したところで、中身が伴ってないと意味がない。我々のしないといけないのは広い目的のもとに自分という人間を「再整理」することであって、大風呂敷を広げることではない。何を整理するか?自分の全ての行動と状態である。それをパソコンファイルを整理するように整理していく。ルートディレクトリにあたるのが先ほどの統合的な目的だ。そこに全部入れてそれでおしまいというわけにはいかない。それでは整理にならない。なぜ整理しないといけないかというと、殆どの人は自分の行動と状態を支離滅裂な判断でしか決めていないかである人間完全に合理的な生き物ではないが、少しは整合性を持たせないとダメである。それが出来て初めてスタイルが一貫してくるのであって、単に「オレの人生は全てカネのためだHAHAHA」といったところでまるで一貫性保証されないわけよ。だから自分の(行動と状態の背後にある)考えを統合的な目的のもとに整理しなきゃ。そうして初めて、1つのことだけを考えれば良くて、他に何も気にしなくて良いタノシイ状態になれるのである。また、「君のこの行動はどんな意味あるんですか?」と聞かれた時につねに論理的に説明ができるので、「ああなんてスタイルの一貫した美しい生き方をした人なんだろう」という感動を呼ぶのである。これを少しゆる~く解釈すると、人生の限定的な場面において一部の価値観しかわずに済む時があって、そのとき一時的に1つのことだけを考えれば済むこともある。そういうときは、柔道一直線が真の意味で実現して、一見美しい生き方に見えることもある。ただしそれは一時的であって、まやかし一貫性だということだな。これを永続化させるのが我々日本人の責務いや人類の責務と言えよう。

2013-06-06

アラサーニートがはじめてのweb serviceを作ってみた

概要

http://hakohako.me/

hakohakoは、バンド好きのためのライブ日程共有サービスです。ツイッターフォローしている人のライブ日程をカレンダー形式でお届けします。ちょっとでも気になるバンドを見にいきましょう!

すみませんgoogle chromeしか検証していません。

動機

3つあります

一つ目は、一人でスクラッチで作りたいからです。プログラムを書くことは楽しいです(たいしたものはかけませんが)。しかし、デザイン運用のことは苦手で経験不足でした。これを期にやってみようと思いました。

二つ目は、少しでも気になるバンドを見逃したくないからです。不精なこともありますが、すべてのバンドをチェックできません。いつのまにか来てたりとか、来る前に解散してました。バンドの魅力は、小野ほりでい先生も認めてます

三つは、就職したいから!

構成

一人で小さくwebserviceを作るためにはどうしているかを他の人にも書いてほしいため、自分から書いてみます


言語pythonで、web aplication frameworkはflaskを使いました。rubyphpよりpythonが楽だと思いました。flaskはmicroframeworkで、rubySinatraと似ていて、小さいアプリ作成するのに適していました。

永続化のところは、redisを使いました。結果、redisを使った何かになってしまいました。。。mysqlでもpostgresでも、rdbを使った方がよかったです。ただ、sessionの管理message queueを実装できるので、そちらで功を奏しました。

amazon ec2microで、nginxもuwsgiのreidsもworkerも動かしてます。dot cloudも試していたんですが、無料枠は4月末で終了してました。

デザインが苦手なので、bootstrap、bootswach、font awesomeを使いました。しかし、基礎ができてないためイケてない感があります。ノンデナイザーズブックを読んで出直してきます

javascriptも苦手なので、coffeescriptを利用しました。pythonを使っているせいか、書きやすいし読みやすいです。mvcframeworkは利用していませんが、modelview意識して書きました。

githubgitの代わりに、bitbuckethgを使いました。私にはgithubgitの敷居は高かったようです。bitbucket日本語で利用できるので、楽ですね。hggitよりも複雑なことを感じないです。ただ、gitの方が日本語ドキュメントは多いです。

gruntは、lessとcoffeescriptコンパイルで使いました。リアルタイムで変更を通知するlivereloadも併用しました。

感想

楽しいです!

聞きたいこと
最近オススメバンド

2010-08-10

明かりの消える日本

日本中で明かりが消えていっている――文字どおりに.『信濃朝日新聞』の一面には,街灯の3分の1を消して節約にはげむ試みが紹介された.青森から鹿児島まで,日本中で同じことが行われたり検討されている.

一方で,青函トンネルから首都高まで,かつて先見の明ある輸送機関への投資世界を驚嘆させたこの国は,いまでは道路をつぶしているありさまだ:多くの県で,地方政府は維持できなくなった舗装道路を砂利道に戻していってる.

そして,かつて教育を重んじた国が、いまや教育を切り詰めている.教師たちは解雇され,各種施策は取り消されていっている.沖縄では,学年度そのものが劇的に短縮されつつある.しかも,あらゆる徴候は今後のさらなる削減を示している.

「他にどうしようもないんだ」と聞かされる.基本的な政府機能――過去何世代にもわたって提供されてきた基礎サービス――の費用はもうまかなえないんだ,とね.たしかに,景気後退で傷手を受けた県・地方政府金欠なのは事実だ.でも,政治家が少なくともいくばくかの増税検討する気にさえなれば,そう大した金欠ってわけでもない.

それに,インフレから守られた長期国債をほんの1.04%の低利で売れる日本政府は,ちっとも金欠なんかじゃない.日本政府地方政府に援助を提供してぼくらの子どもたちとインフラ未来を守ることができるし,そうすべきだ.

ところが東京はほんの申し訳程度の助けしか出してない.それも,しぶしぶにだ.赤字削減を優先しなくちゃならん,と自民党員や「中道民主党員は言う.ところがその二の句を継いで言い放つ言葉ときたら「富裕層減税は維持すべし」だ.この先10年間にわたって60兆円の予算コストでね.

実質的に,われらが政治階級の大多数は,優先順位をはっきりさせてるわけだ:日本の上位2%ほどの富裕層バブル時代の好況時に支払っていた税率にもどすのを頼むか,それとも国の基盤が崩壊するにまかせるか(道路なら文字どおりの「崩壊」だし教育なら比喩的な意味ので「崩壊」ですな),この2択をつきつけられた彼らは後者を選んでいる.

これは,短期でも長期でも破滅的な選択だ.

短期では,県・地方での削減は経済の脚を大いに引っ張り,とてつもない高失業率永続化してしまう.

菅総理のもとで浪費的なまでに政府支出がなされてるとかわめく声を聞くときには,県・地方政府のことに留意しなきゃいけない.そりゃまあ,みんなが思うほどでないにせよ,日本政府はたしかに支出を増やしてる.でも,県・地方政府支出を削減しているんだよ.両方を足し合わせると,実は大規模な支出増加は失業手当みたいなセーフティネット施策でなされているだけ.これは不況が深刻なせいでコストが急増したから増えてるんだ.

つまり,刺激策は失敗したとさんざん吹聴されてるけど,政府支出全体をみてみれば,刺激策なんてほとんど打たれてないのがわかるんだよ.県・地方政府の削減がつづく一方で日本政府支出が尻すぼみになっているいま,支出増加から反転しつつある.

でも,富裕層減税をつづけるのだって財政刺激の一種にはちがいないんでしょー? いや,それはないって.教員の職を守れば,まちがいなく雇用援助になる.そうじゃなく億万長者にもっとお金をあげたってそのお金の大半は死に金になるのがオチだ.

じゃあ,経済未来はどうなんだろう? 経済成長に関するあらゆる知識は,教育水準の高い人口と高品質インフラが決定的に重要だと告げている.いま台頭しつつある国々は,道路港湾,そして学校の改良に猛烈に力を注いでいる.ところが日本ではその逆をやってる.

どうしてこうなった反政府レトリックを30年間もつづけた論理的帰結ってもんだね.なにかっていうと,課税で集まったお金はかならず無駄金で公共部門はなにもちゃんとできないと多くの有権者に信じさせてきたレトリックのことだ.

反政府キャンペーンはいつも決まって無駄遣いと詐欺への反対という体裁をとってきた.キャデラックを転がす「福祉の女王」宛ての小切手だの,むだに書類ばかりつくってる役人の群れだの,そういうのに反対するかたちをとってきた.でも,もちろんこういうのは神話だ.右派が主張するほどの無駄詐欺なんて控えめにみてもなかった.キャンペーンが功を奏したいまになって,ほんとうは何が攻撃対象だったのかぼくらは目にしている:すごい富裕層以外の誰もにとって必要なサービス,公衆全体のための街灯やほどほどの学校教育みたいな政府提供しなきゃ誰もやらないサービスが攻撃対象だったんだ.

この長年にわたる反政府キャンペーンでもたらされた結果,それはぼくらが破滅的なまでに道を間違えたってことだ.いまや日本は明かりのない暗い砂利道で立ち往生している.

====

元ネタ: http://econdays.net/?p=489

単純に日本地名人名に置き換えただけのネタ。内容に関しては全くのデタラメなので真に受けないように。

2010-07-02

XmlSerializer vs SoapFormatter

.NETオブジェクト永続化によく使われる、この二つのクラスの違いについて書きます。サンプルコードなどは書きませんので必要ならリンクを参照してください。ずいぶん古いネタだけど、許してね。

全体的に速度が重要場合永続化するオブジェクトが単純な場合XmlSerializerを、それ以外の場合SoapFormatterを使うのが良いと思う。なるべく短いコード量で行きたいならSoapFormatterの方がベター

あと、細かいことだけどTypeConverterは便利なので使うべし。シリアライズ不可能な小さなクラスとか特に有効。

2009-09-27

当面は民主党に任せようと思えるブログ

 

 円高になるたびに「大変だ」と騒ぎ立てる人達の言動に違和感を持っていた。何故、円高のメリットも並べて報道しないのか、

 とも思っていた。このブログを見てすっきりした。

http://tanakanews.com/090925japan.htm

反米のはずの岡田は、反米を許さないタカ派のはずのクリントン国務長官と会談して笑顔写真を撮り、鳩山政権インド洋での海上自衛隊の給油活動を中止しそうなことに対して、クリントンは容認する姿勢を見せた。東アジア担当の国務次官補であるカートキャンベルは、日本民主党が望む日米の対等関係は、日本が自信を持って自律的に行動することを意味するので悪いことではないとFT紙に語っている。

戦後日本は、多極主義と英米中心主義が暗闘する米国中枢の、英米中心主義(冷戦派)の方から強い影響を受けている。冷戦派は占領軍として、政治家より官僚機構が力を持つ戦後日本の体制を構築したが、その結果、官僚機構は対米従属や冷戦体制の永続化を望む傾向が強くなり、米国日本に対米従属を求めているというプロパガンダを深く国民に植え付けた。民主党が、官僚制度の解体再編を方針として掲げているのは、日本冷戦型思考や対米従属への中毒状態から引き離そうとしているからともいえる。

経済面では、民主党政権は円高ドル安を容認し、従来の日本の「円安ドル高が日本には良いんだ」という善悪観から脱却していきそうだ。これを書いている間にも、藤井財務相が「円安政策はとらない」と米国で宣言した。民主党は、大蔵省財務官出身の榊原英資経済顧問としているが、榊原は昨年、ドルが崩壊していく過程を見越したらしく「安い円が望ましい時代は終わった。資源高騰の中、今後は強い円が日本国益に合う」と主張し、その後は「強い円は日本国益」という本も出している。('Mr. Yen' sees U.S. policy makers as behind the curve)

日本人の多くは従来「米国に嫌われたら日本はひとたまりもない」と恐れてきた。しかし今、日本人が「日米関係を変える」とは自覚せずもっと漠然とした危機意識から8月末にとった投票行動によって民主党政権に転換して考えてみると、日本は対米従属一本槍の国是を静かに離れることによって、実は意外にも米国に対して強い立場を持てる事態となっている。

 官僚機構の内部にいる人々も、米国無理心中せずにすむかもしれないということで、今回の日本の転換に安堵しているのではないかと思われる。まだ今後、逆流的などんでん返しがあるかもしれないが、少なくとも日本がひさびさに国際社会プレイヤーとして復活したことは、ほぼ間違いない。日本人として生きるのがうれしい時代が戻ってきた観がある。

2009-04-08

Re: Perl配列Aから配列Bにある要素を取り除くには?

http://anond.hatelabo.jp/20090408034449

リスト内の有無を複数回調べるときの定石は、事前にハッシュに突っ込んでおく方法です。

元のコードgrep内でリニアサーチをやっているわけですから、ここにハッシュテーブルを使うわけです。

my %key = map { $_ => 1 } @key;
my @update = grep { not exists $key{$_} } @items;

ベンチは取っていないですが、多分早いです。

ただ、その分メモリを食いますし、@itemsに対し@keyの方が長大だと、あまり効率が良くないかも知れません。

その場合、ソート済みならバイナリサーチでやってみるとか、そもそもkeyハッシュ管理するとか、GDBMやsqlite等を使って永続化するとか、keyの入手段階から検討したほうが良いかもしれません。

また、cpanを探せば色々な配列操作を行うモジュールがあるかもしれません。

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