何でもかんでもサブスクリプションって風潮は何とかならんのか
やめてほしい。
先ほど、英単語学習のために英検1級の単語アプリを購入しようとしたのだが、検索に引っかからなかった
先月にはまだ存在していたのだが・・・
どうやら母体となるアプリに吸収されてしまったようだった
簡単に説明すると、母体となるアプリが別にあって、そのアプリの派生アプリというような位置付けであった
どうせならアプリ内課金という形にして、一つのアプリ内で完結してくれていたらな、と思っていたが、別の形でそれが叶ってしまったようだ
なにが起きたかというと、ストアから姿を消したそのアプリは、母体となるアプリのサブスクリプションサービスの一部になっていたのだった！
月額1000円（一年契約なら600円/月）を払わなければそのコンテンツにアクセスできないのである
俺が欲しかったのは「英検1級」の英単語アプリなわけである
たった一つの単語帳のために月額1000円も払うのはさすがにバカバカしい
（1年契約なら600円だが、年間7200円も払えるわけがない。かといって、1000円の状態でどこまで続けるのかという問題もある）
これはパス単1級のアプリ版なので、書籍版を見てみると 1,800円 だった
たった2か月でこれを越えてしまうではないか！
紙の書籍にしないのは、いつでもどこでも単語を勉強したいからである
スマホ一つで勉強できるのは非常にありがたい。満員バス、電車の中、場所を選ばずいつも通りの体制で勉強が可能だ
特に私の場合は仕事帰りのバスの一定区間を単語勉強の時間にあてており、座れないこともしばしばなので、スマホ版で勉強することは譲れないのである
話が脱線したが、とりあえず、単品で買わせてほしいのである
月額払えば全コンテンツ使い放題だよ！と言われたところで、最初から私の目的は「英検1級」の単語帳なのである
大体、数十の単語帳を全部やるやつなんておるんかい。おらんやろ
サブスクリプションの利点は、基本的に月額を払っておれば、サービス使い放題という点である
提供者側にもユーザに発生するイニシャルコストを最低限に抑えて、導入障壁を下げるメリットがある
Adobe はそれで飛躍的に業績を伸ばした
しかし、それは Adobe の製品が高すぎたからであり、サブスクリプションのほうが圧倒的にお得だからである！
また、音楽ストリーミングサービスのサブスクリプションについても肯定する
音楽というのは、毎日生み出されるコンテンツであり、また聞き手にとっても聞きたい曲は日々増えていくものである
よって、聞き放題というサービス形態は最適解と言えよう
いろいろ話が飛んでしまったような気がするが、とりあえず何でもかんでもサブスクリプションは間違っている
特に英単語アプリには断じて不適である。単語帳そのものの単価が安い上に、大量の単語帳をこなすニーズなどないからである
単語帳を購入の一回きりの制度に戻すか、月額100円くらいの低単価にするか、どちらかしかないだろう
まあ、このサービス以外単語帳アプリ無いに等しいので、アプリという媒体にこだわる限り、課金せざるを得なくなるかもしれんが・・・・
wikipedia の MVC を訳してみた 最後
最後です。
（原文）
Goals of MVC
This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (February 2017) (Learn how and when to remove this template message)
Simultaneous development
Because MVC decouples the various components of an application, developers are able to work in parallel on different components without impacting or blocking one another. For example, a team might divide their developers between the front-end and the back-end. The back-end developers can design the structure of the data and how the user interacts with it without requiring the user interface to be completed. Conversely, the front-end developers are able to design and test the layout of the application prior to the data structure being available.Code reuse
By creating components that are independent of each other, developers are able to reuse components quickly and easily in other applications. The same (or similar) view for one application can be refactored for another application with different data because the view is simply handling how the data is being displayed to the user.Advantages & disadvantages
Advantages
Simultaneous development – Multiple developers can work simultaneously on the model, controller and views.
High cohesion – MVC enables logical grouping of related actions on a controller together. The views for a specific model are also grouped together.
Low coupling – The very nature of the MVC framework is such that there is low coupling among models, views or controllers
Ease of modification – Because of the separation of responsibilities, future development or modification is easier
Multiple views for a model – Models can have multiple views
Disadvantages
Code navigability – The framework navigation can be complex because it introduces new layers of abstraction and requires users to adapt to the decomposition criteria of MVC.
Multi-artifact consistency – Decomposing a feature into three artifacts causes scattering. Thus, requiring developers to maintain the consistency of multiple representations at once.
Pronounced learning curve – Knowledge on multiple technologies becomes the norm. Developers using MVC need to be skilled in multiple technologies.
（訳）
MVCの到達点
同時の開発
MVCはアプリケーションを様々なコンポーネントに分割するので、開発者はお互い干渉することなく、並行して別々のコンポーネントに取り組むことができる
例えば、チームは開発者たちをフロントエンドとバックエンドに分けるかもしれない
バックエンドの開発者は完成したUIを必要とせずに、データの構造とどのようにしてユーザがそれを扱うのかを設計することができる
反対に、フロントエンドの開発者は利用可能になるデータの構造に先立って、アプリケーションのレイアウトを設計し、テストすることができる
コードの再利用
お互いに独立したコンポーネントを作ることによって、開発者は他のアプリで素早く、また簡単に再利用することができる
ビューは単に、どのようにしてユーザにデータを表示するのかを扱うだけなので、1つのアプリケーションで同じ（もしくはよく似た）ビューは別のデータでもう1つのアプリケーションをリファクタリングすることができる
長所と短所
長所
同時の開発・・・複数の開発者が同時にモデル、コントローラ、モデルに取り組むことができる
高凝集・・・MVCはコントローラで一緒に関連したアクションの論理的グルーピングを可能にする
特定のモデルのためのビューはまた、一緒にまとめられる
低結合・・・MVCフレームワークの本質はモデル、ビュー、コントローラ間の低結合にある
修正の簡単さ・・・責務の分離のため、その後の開発と修正がより簡単だ
モデルのための複数のビュー・・・モデルは複数のビューを持つことができる
短所
コードのナビゲービリティ・・・フレームワークのナビゲーションは新たな抽象概念の層を導入し、ユーザにMVCの変容する標準に適応することを要求するので、フレームワークのナビゲーションは複雑になりがちである
多数の人工物の一貫性・・・機能を3つの人工物に分解することは分散をもたらす
このように、同時に多数のリプレゼンテーションの一貫性を維持するための開発者を必要としている
明白な学習曲線・・・多数のテクノロジーの知識は標準となっている
MVCを使う開発者は様々なテクノロジーに習熟している必要がある
wikipedia の MVC を訳してみた 続き
こんばんは(？)
今日は昨日の続きを訳していきたいと思いますが、前回の訳に致命的な誤りがありましたので、謹んで訂正致します
line 3 )
The MVC design pattern decouples these major components allowing for efficient code reuse and parallel development.
誤）MVCデザインパターンは効率的なコード再利用と相似な開発を許す主要なコンポーネントを分離する
ではなく、
正）MVCデザインパターンはこれらの主要はコンポーネントを分離し、効率的なコードの再利用と相似な開発を可能にする
が正しい訳でした
原因は、'allowing' 以下を、'components' を修飾する現在分詞だと勘違いしたからです
分詞構文と捉えるのが正解でした（文法的にはどちらの解釈も非文ではありません）
さて、今日は 'Use in web applications' まで訳します
（原文）
History
One of the seminal insights in the early development of graphical user interfaces, MVC became one of the first approaches to describe and implement software constructs in terms of their responsibilities.Trygve Reenskaug introduced MVC into Smalltalk-76 while visiting the Xerox Palo Alto Research Center (PARC) in the 1970s. In the 1980s, Jim Althoff and others implemented a version of MVC for the Smalltalk-80 class library. Only later did a 1988 article in The Journal of Object Technology (JOT) express MVC as a general concept.
The MVC pattern has subsequently evolved, giving rise to variants such as hierarchical model–view–controller (HMVC), model–view–adapter (MVA), model–view–presenter (MVP), model–view–viewmodel (MVVM), and others that adapted MVC to different contexts.
The use of the MVC pattern in web applications exploded in popularity after the introduction of NeXT's WebObjects in 1996, which was originally written in Objective-C (that borrowed heavily from Smalltalk) and helped enforce MVC principles. Later, the MVC pattern became popular with Java developers when WebObjects was ported to Java. Later frameworks for Java, such as Spring (released in October 2002), continued the strong bond between Java and MVC. The introduction of the frameworks Django (July 2005, for Python) and Rails (December 2005, for Ruby), both of which had a strong emphasis on rapid deployment, increased MVC's popularity outside the traditional enterprise environment in which it has long been popular. MVC web frameworks now hold large market-shares relative to non-MVC web toolkits.
Use in web applications
Although originally developed for desktop computing, MVC has been widely adopted as an architecture for World Wide Web applications in major programming languages. Several web frameworks have been created that enforce the pattern. These software frameworks vary in their interpretations, mainly in the way that the MVC responsibilities are divided between the client and server.Some web MVC frameworks take a thin client approach that places almost the entire model, view and controller logic on the server. This is reflected in frameworks such as Django, Rails and ASP.NET MVC. In this approach, the client sends either hyperlink requests or form submissions to the controller and then receives a complete and updated web page (or other document) from the view; the model exists entirely on the server. Other frameworks such as AngularJS, EmberJS, JavaScriptMVC and Backbone allow the MVC components to execute partly on the client (also see Ajax).
（訳）
歴史
GUIの開発初期段階では将来性のある洞察の1つであったMVCは、それらの責務に関するソフトの構築を述べて、実行するための最新の手法のアプローチの1つとなった
Trygve Reenskaug は1970年代にゼロックス社のパロアルト研究所を訪れていた際、MVCをSmalltalk-76に移植した
1980年代に、Jim Althoff と数名はSmalltalk-80のクラスライブラリのMVCのバージョンを実行した
その後、The Journal of Object Technology (JOT) の1988年の記事が一般的なコンセプトとして、MVCを伝えた
その後、MVCパターンは進化して、HMVC、MVA、MVP、MVVMやその他のコンテキストにMVCを適応させるもののような派生を生み出した
元々、Objective-C で書かれていて（ほとんど Smalltalk から借用）、MVC原則に助けられた、1996年の NeXT の WebObject の導入から、ウェブアプリでのMVCパターンの利用は爆発的に普及した
WebObject が Java に移植されてから、MVCパターンは Java の開発者の間で普及した
その後、2002年10月に公開された Spring といった Java のフレームワークが Java とMVC との繋がりを強くした
高速なデプロイを重要視する Django (2005年7月、Pyhton用) や、Rail (2005年12月 Ruby用) のフレームワークの導入はそれが長く人気のあった従来の企業の環境以外では普及した
MVCフレームワークはいまや、MVCを採用していないウェブツールと比べて巨大なシェアを獲得している
ウェブアプリでの使用
MVCはもともと、デスクトップコンピューティングで開発されるものだったが、主要なプログラミング言語でウェブアプリのアーキテクチャとして広く適応してきた
MVCを実行するいくつかのウェブのフレームワークが作られている
これらのソフトウェアフレームワークはそれらの解釈の点で異なっている
主にMVCの責務はクライアントとサーバの間で分離されるという方法だ
いくつかのウェブMVCフレームワークでは、たいていサーバ上に全てのモデル・ビュー・コントローラを置く「シンクライアント」の方式を取っている
これは、Django、Rail や ASP.NET MVC のようなフレームワークに反映されている
このアプローチでは、クライアントがハイパーリンクによるリクエスト、あるいはフォームの送信がコントローラに送られる
その後、ビューから完了した最新のウェブページ（もしくはその他のドキュメント）を受け取る
モデルは完全にサーバに存在しているということだ
AngularJS、EmberJS、JavaScriptMVC や Backbone のようなその他のフレームワークでは、MVCコンポーネントにクライアント上で一部を実行することが可能だ（Ajax を参照）
（ここまで）
・・・・・
今回も意味不明な訳がいくつかあります・・・。また明日見直してみます。では！
wikipedia の MVC を訳してみた
なぜ急に？って言われると、なんとなくですｗ
本文はこちらとなっております
なお、訳は時間の都合上 'Description' までとなっております
(原文)
Model–view–controller is commonly used for developing software that divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.[1][2] The MVC design pattern decouples these major components allowing for efficient code reuse and parallel development.
Traditionally used for desktop graphical user interfaces (GUIs), this architecture has become popular for designing web applications and even mobile, desktop and other clients.[3] Popular programming languages like Java, C#, Ruby, PHP and others have popular MVC frameworks that are currently being used in web application development straight out of the box.
Descriptions[edit]
As with other software patterns, MVC expresses the "core of the solution" to a problem while allowing it to be adapted for each system.[4] Particular MVC architectures can vary significantly from the traditional description here.[5]
Components[edit]
- The model is the central component of the pattern. It expresses the application's behavior in terms of the problem domain, independent of the user interface.[6] It directly manages the data, logic and rules of the application.
- A view can be any output representation of information, such as a chart or a diagram. Multiple views of the same information are possible, such as a bar chart for management and a tabular view for accountants.
- The third part or section, the controller, accepts input and converts it to commands for the model or view.[7]
Interactions[edit]
In addition to dividing the application into three kinds of components, the model–view–controller design defines the interactions between them.[8]
- The model is responsible for managing the data of the application. It receives user input from the controller.
- The view means presentation of the model in a particular format.
- The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.
(訳)
概要
モデル・ビュー・コントローラはアプリケーションを3つの相互に連結されたパーツに分けるソフトウェアを開発するために利用される
これは、送られるユーザへの情報と受け入れられるユーザからの情報から内部の情報の説明を分離するために行われる
MVCデザインパターンは効率的なコード再利用と相似な開発を許す主要なコンポーネントを分離する
伝統的にこの構造はデスクトップのGUIとして使われるが、ウェブアプリ、モバイルアプリ、デスクトップアプリやほかのクライアントで普及している
Java、C#、Ruby、PHPなどの人気のあるプログラミング言語にはすぐに使うことのできるウェブアプリ開発用の人気なMVCフレームワークがある
説明
他のソフトのパターンと同様に、MVCが「解決の核心」をそれぞれのシステムに適応させることを許している間、それを問題に伝えている
特定のMVCアーキテクチャはここでの伝統的な説明とは著しく異なっている可能性がある
コンポーネント
- モデルは、パターンの中核を担うコンポーネントだ
それは、問題領域についてのアプリケーションのふるまいとユーザインターフェイスとの独立を表します
それは、アプリケーションのデータ、ロジック、ルールを扱う - ビューは、図のような任意の情報の出力をする場合がある
多くの同じ情報のビューは、経営の棒グラフや、会計係の表のようにすることが可能だ -
3つ目のコントローラは、入力を受け入れ、それをモデルおよびビューへのコマンドへ変換する
相互作用
アプリケーションを3種類のコンポーネントに分けることに加え、モデル・ビュー・コントローラはそれらの間の相互作用を定義する
- モデルは、アプリケーションのデータを操作する義務がある
それは、コントローラからユーザ入力を受け取る - ビューは、特定の形式の見栄えを示す
- コントローラは、ユーザ入力に反応し、データモデルのオブジェクトのインタラクションを実行する
コントローラは、その入力を受け取り、必要に応じてそれを検証し、それからモデルへ入力を渡す
(ここまで)
反省
いやー・・・相当酷いですね・・・ｗ
途中上手く訳せず意味不明な日本語もいくつかあります
特に「解決の核心」、これは酷いです。なんとなくニュアンスは伝わるのですが、いざ日本語に訳してみようとすると、良い訳が浮かばず・・・
他にも、「traditionally」は学生時代「伝統的な」と訳していたので、それが染みついていたのですが、「従来の」と訳すことも多いようです
ITに従事する者にとって、英語は必須。日ごろから英語に触れていかないとダメですね
