「ビジネスロジック」を含む日記 RSS

はてなキーワード: ビジネスロジックとは

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2017-01-29

優秀な外国人技術者活用できている会社

http://anond.hatelabo.jp/20170128125048

優秀な外国人技術者活用できている国内企業一社知っている。とても感銘を受けたのでここに書いておきたい。

ある分野向けの業務システム(参入している企業10社以上ある)を開発販売しているベンチャーだ。

システム連携お仕事をさせていただいたことがあるが、まずその技術力の高さに驚かされた。

2015年前半の時点で競合他社のネイティブアプリよりも高速・多機能ものを、JavascriptによるSPA実装していたのだ。

ネイティブアプリのようにサクサク動き、ビジネスロジックが複雑で巨大なアプリケーションjsでは作成できないと思っていたが、

実際に動くものを突きつけられてはぐうの音も出ない。

次にAPI仕様書提供を受けたがこれも驚き。

今まで見てきた競合他社のAPI仕様書ベンチャー系によくある雑なドキュメントが多かったが、

書籍ですか?」というほどよく編集されSIerも真っ青なほどよくできたものだった。

API品質言わずもがなである

最後仕事スピードが異常に速い。こっちは1か月くらいかなと思っても1週間のうちに上がってくる。

そんな早くて品質大丈夫かと思ったが、全く問題はなかった。


小規模なベンチャーなのにどうしてこれほど高品質・多機能wel documentedな製品を高速に作ることができるのか?

その会社業界の中でも資金力に勝っているわけではなく、有名なエンジニアがいるという話も聞いたことがなかった。

直接その会社CEOに聞いてみたところ、まあタイトルのとおり、理由は「優秀な外国人技術者活用できている」からだった。



あれほどの成功例を見せつけられてしまうと、ビジネスサイドとマネージャー英語を話せる日本人がいれば、日本人エンジニアは最小限でいいかもなと思ってしまいました。

というわけで「優秀な外国人技術者活用」できたらこんないいことあるよという話でした(大多数の日本企業はできないと思うが)。

2016-10-17

http://anond.hatelabo.jp/20161017164515

ビジネスロジックModelに、とかサービス層に、とか言われて、困る感じか

1画面1機能ならViewとControllerで十分なんだよね

同じ機能複数画面で提供しようとすると、Controllerに処理書くスタイルだとコードが重複だらけになるんだよね

それを共通化しようってしたときに、ソフトウェアアーキテクチャとかが出てくるんだよね

教科書としては「エンタープライズ アプリケーションアーキテクチャパターン」とかあるけど、難しいし、理解してない人のほうが多いし、人によって言ってること変わるんだよね

2016-03-27

http://anond.hatelabo.jp/20160327184113

逆に聞くけど、

「きっちりビジネスロジック分離したまともな設計

を細部まで指定してプログラマに渡すの?

それ、自分で書いたほうが速くない?

なんのために設計書くの?

http://anond.hatelabo.jp/20160327184113

そんじゃあ、中身がコピペ祭りになるか、きっちりビジネスロジック分離したまともな設計になるかはプログラマ任せって感じ?

そうだよ。

コードレビューはするの?

基本はプログラマコーダー?)同士でやってもらってる。


前提として、発注する自分コードかけるっていうのが自制心をかけているような気はする。

だけど基本は人同士のやりとりなので、お互いを信頼してあまり口出しはしないようにしている。

その最低限のラインを、自分の中で下記で縛ってる

それ以外なら、コーダーがやりやす環境がいいのは間違いないし、

しろ自分がこれじゃパフォーマンス悪そうだ、設計が難しそうだ、っていうときコーダーに聞くから

http://anond.hatelabo.jp/20160327183851

そんじゃあ、中身がコピペ祭りになるか、きっちりビジネスロジック分離したまともな設計になるかはプログラマ任せって感じ?

コードレビューはするの?

2014-11-06

緩やかな能動的行動の死

組織も人も最適化の果てにあるのは緩やかな死

http://blog.masuidrive.jp/2014/11/06/optimization/

これを読んで自分の心境とマッチした。

現状の憂いなき状況(支離滅裂に書いてる)

わけわからんほどのメーリングリストが飛んでくる。またそれを追えという

>>は?そんな時代は終わったはずなんだけども。。。。。。。

>> メールフィルタリングを共有化すればいいじゃん

>>> えっとメールというツールの使い方をそもそもとして間違えているよね。今の時代

その場しのぎのビジネスロジックの追加でやっている事はシンプルなのに複雑性をます運用保守

>> 守る事のほうがビジネス価値証明するのが辛いのにそれを呆けた結果でしょ?

>> それを真剣議論した?時間が風化させるものほとんどだけども、それを保守する人間に「そんな悲しい事いわないでよ」って言われてもどんなに頑張ってもモチベーション上がらんでしょ。。

世の中そんな綺麗なシステム存在しないし、そんな夢のようなシステムがある所に自分が行けることはないとは分かったとしても、せめて中二病的な何かが日々があればいいと思うけどもそれも何もない。

>> デプロイ一人ぼっち(大きな声で「リリースいやっほーい!!!!!!!」って声だしてもいい雰囲気はナシ

>> IEで動かせ (は?お前ちょっとそこのヨドバシカメラwindows8買って素敵って思えるならIE動かせって言っても許すよ)

改善をするものは世の中にあふれているはずなのに職人芸を要求するチーム(組織かもしれんね)。

>> よってセグメンテーションを小さくフォーカスすることが正義になる。

>> はいはい。言った言わないがビジネスにおいていいことなんでしょ。それを証明するためにダルい事すんだよね。

これだけアカンな事が一杯溢れていると燃えるよねと最初思ったけど、トドメ長老陣の洗脳化作

>> 離職率が高い所しか基本長くいなかったけれども、長期的にやっている人がこれほどまでに事業部を歪んだ形にさせることは逆に学んだ。

頭がいいってなんでしょね?とか賢いって思ってるかもしれんケド結局目の前の事を棚上げにした結果でしょ。

そんな事を考えてる自分に嫌気が差してくるから最近能動的な振りして、何も考えないようにしたさ。

何故ならば割り切ったから。

上記の事は全部個に対していってるわけではない。

みんな大なり小なり思うことであり、その人がそう言った訳ではなく集団的心理がそうさせただけ

極論言うと誰も悪くはない

だったら潔く

死にたい」って気軽に言えるカオスのほうが幸せだわ。マジで

2014-02-06

http://anond.hatelabo.jp/20140206161838

ん?なんか勘違いしてね?

SIerはとにかく何でもいいからシステム導入したいし、顧客ビッグデータ!とか言いながら

日経ビジネス程度の知識しかないんだから実質的にやることの内容はどうでもいいんだよ。

出てくる結果的には回帰分析程度のことやっとけばSIer顧客おじさんは満足するし(それ以上のこと見せられてもよくわからない)、

あとあと困ったことになれば保守契約SIerおじさんは儲かってハッピーになる。

要するにそれだけのことを「業務知識豊富SEビジネスロジックを深く理解して顧客価値を最大化します!」とか言いながらやるだけ。

日本の(顧客側)大企業で、ソフトでマジに儲けてる会社なんて存在しないから、他の部門が出してる収益を食い潰してシステム部門のおじさんが仕事のような何かをしてるだけ。

2010-07-09

ビジネスロジックをストアードプロシージャで実装してはいけない

ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジッククライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。

ストアードプロシージャと単体テストは食い合わせが悪い

RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語デバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語記述した場合よりもはるかに時間がかかる。

また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。

さらに、カバレッジツールは大抵の場合使えないだろう。

ストアードプロシージャは、たいていの場合、静的解析が行えない

ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。

ストアードプロシージャは、バージョン管理されたコードとの整合性に問題がある

仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイル管理し、それをバージョン管理システムに含めたとしても(というか、最低そうすべきなんだが)、あるリビジョンコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。

ではトリガーはどうなのだ

リガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。

さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。

では一体いつストアードプログラムを使うのか

一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合

もう一つは、複数クライアント言語で同一データベースを使用することが決定済みな場合

2009-08-04

逆宣伝という発想

特定の事物を極力広めないようにするにはどうすればいいか?

メジャーになると消費され使い古されてしまう」というアンチ消費主義思想の俺にとって、このことは重要命題だ。

なるべく周知させない活動のことを仮に「逆宣伝」と呼ぼう。逆宣伝するには、どうしたらいいか?

これは実に難しい。なぜなら宣伝活動であれば、他者がどんなにあがこうと、ある程度のレベルまでは達成できる。

例えば、お金を沢山使うことで周知させたりできる。しかし、逆宣伝の場合、他者がクチコミなどで宣伝してしまうリスクがある。

いくら頑張ろうが、有志の手で周知させられる恐れがあるため、「いかに人々の宣伝活動を抑制するか」が上記の命題達成のためのサブ課題となる。

また、「情報を一定の会員の内部だけで流れるように囲い込むこと」も重大なサブ課題である。

非常に難しい命題ではあるが、やる価値はある。

ちょっと考えてみて欲しい。

いまの世の中はネットがあるため、ネットで誰かが晒す(ネットクチコミすることをあえてこう呼ばせてもらう)ことで、

たちまち広まってしまい、良質なもの・興味深いものであれば、いとも簡単に周知されてしまう可能性がある。

その結果、我々が普段接している良い商品サービスというのは、大多数が宣伝により周知され消費され使い古されたものである。

大衆の手垢のついていない、純粋意味で良質な商品サービスというものが皆無に近い。

ビジネスロジックに乗っかった、一般人の要求に迎合したような商品サービスばかりで、まったく吐き気がする。

オカネや多数決に支配されるとワンパターンになるしロクなことがない。

よくネットの人が「オープン正義」的なことを言っているけど、共有というと聞こえは良いが、ぶっちゃけそれ大衆化でしょ。

確かにオープン情報の流れも大切だと思うけど、クローズド情報の流れにも価値があることを忘れてはならない。

追記:逆宣伝という言葉にはネガキャンという意味があったのか。じゃあ、そのままだけど、「宣伝防止」とでも言おうか。

2008-02-15

はてなincだめだったってことかな?

アルバイトの1人も集まらなかったっぽくね。

結局、しなもんジャックをご挨拶させただけで終わったのかな?

相変わらず迷走しているようにみえてハラハラするよ。はてなは。

走ってから考える。もしくは走りながら考えるタイプなのか?

経営層全員? www

はてなの営業分析とかしてきたけど、相変わらずビジネスロジックがみえない。

みえないというか、何を目指しているのかがまったくみえない。

まだ一昨年の方が「つながるサービス」とか、そういうビジョンがあったきがする。

去年のテーマを振り返ったときに、どう評価していいかわからない。

過去につくったサービスが衰退期にはいったものがでてきて資産が遺産に変わって重荷になりはじめた一年か?

アメリカ目指したのはアツかったんだけどな。

一年でどれくらい経営者としての見識やネットワークが広がったのだろうか。

21人の会社で、東京京都アメリカって…

いくらなんでも戦線をひろげすぎじゃないかな。

狭い範囲で動いてれば個人の能力で勝てる目もあるけど、兵站が確率できないまま戦線広げたら身動きとれなくなるだけじゃないかな。

何か考えがあるのだろうか?

競業相手とマーケットの奪い合いでユーザー数増える見込みないけどサービスの向上だけ要求されるという事態をあまり意識してないのかな?

サービス数も拠点数もちょっと保守、防御コストのことを考えると自分なんかはゾッとしてしまうが、いったいこれはなんだろう。

ノーガード作戦なのだろうか。

サービスの完成度は8割にすればデバックコストも減らせるし、

ユーザーの囲い込みを考えなければ保守コストも減らせるぜっ!って考えかなw

去年ははてなハイクとかスターとか既存のユーザーに訴求するものはあったけど新規ユーザーを引き寄せるものではなかったと思う。

あせっちゃうよね。。。

そんな状況で京都になんて分散してていいのかな……。

アメリカにいったのにアメリカユーザが獲得できていない。

新しい収入モデルもつくれていない。

相変わらずツーリング経営だ。

マーケットが伸びてる時期だから、こういうやり方あってるのかな・・・

せっかくうまくいってるのにもったいないとか思ってしまう。

わからん。。。

2008-02-11

http://anond.hatelabo.jp/20080210232409

テレビだと電波だから確実に送信されるというメリットはあるよね。

電波といっても結局山も越せないのでいまいちなきもするけど。

地上派デジタルとかインターネットテレビ番組が使用されないのも、アーカイブされないのも完全に利権絡みなんじゃないの?

もっといえば有料チャンネルが国内軒並み苦戦したり潰されてるのもその関係なんじゃないの?

日本テレビ局なんて放送法だけが頼りみたいなもんなんだし。

番組が面白くてまた見たいと思わせるというよりインパクトだけでチャンネルを変えさせずに視聴率を稼いで高い広告料をふんだくる!これがビジネスロジックだから。

日本ぐらいらしいぜ視聴率が10%越えちゃうぐらいチャンネル数が少ない国ってば。

中国ですらゴールデンタイム視聴率が1%いけば人気番組いうぐらい分散してると聞いたよ・・・

よくしらんのだけど、スパーボールみたいな人気番組日本紅白みたいにひとつのチャンネルでだけで独占的に放映されてるの??

こんだけみんなが同じメディアに触れてる国は他にないような気がするな。

視聴率10%だぜ。どんだけおまえら同じテレビを同じ時間に見てるんだよって話しだよ。

日本でさ、MLBみたいな放映権料で稼ぐ仕組みはちょっと難しそうじゃん?

あくまで読売テレビ新聞巨人軍だもんな。

2007-12-17

エンジニアスイーツ

完全に俺の私見だが、

エンジニアハードウェアに近づくに連れて、

辛いものが好きになって、アプリケーションに近づくにつれて、

甘いものが好きになっていくような傾向があるように感じる。

ハードオタクココイチ5辛以上)

回路設計コーディングココイチ3辛以上)

バイナリアンカレー/激カラらめーん大好き)

DB/サーバ管理(カレーは中辛です。)

ビジネスロジックカレー王子様)

WEBインタフェースイチゴに練乳)

デザイナーケーキバイキング

企画(アスパルテーム)

 
ログイン ユーザー登録
ようこそ ゲスト さん