  |
はてなキーワード: 互換とは
言い方を変えればPython2のコードをPython3は甘く見すぎ。
そんな簡単に乗り換えてもらえるわけねーだろ 互換性を切り捨てられるとおもった３陣営は、結局、Python3の互換性ずたぼろだろ
Pyhon3の互換性問題を引き起こしたのは、Python3開発チームの おごりたかぶり、利用者を舐めてる心
互換性は解決に２０年以上かかると思うのが基本。乗り換えてね－で、乗り換えてもらえると思うのが、おごりたかぶり、利用者を舐めてる心が見て取れる。そんなもんえらばれるわけがない。
セーラー万年筆のカートリッジ・インクがウォーターマンの万年筆で使える。
知っている人にはアタリマエのことだったんだろうが
この事実は大きい。
どこでも売っているボディそれはウォーターマン、どこのデパートでもまず売っている。贈り物にも最適
だいたい売ってるセーラ－万年筆の『顔料』インクカートリッジで代用できる。（普通は染料・水に弱い）
これは、おれには新発見 この組み合わせは、おたがいどこにでも売っている別メーカーに互換性がある どれだけ価値ある情報化がわかりにくい
プレゼントでもらったウォータマン万年筆、デパートまで行かなくても、文房具屋のセーラーのカートリッジが使えるよ。 ロフトにもおいてある
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
良い言語だと思うが、不満がある。
という愚痴がある。他人の書いたものを読む分には良い言語だと思うよ。
型ヒントはコンパイル時のエラーにならないじゃん。だったら、いらなくね？タプルは複数の値を返すときに使うのね。Go みたいだね。または Ruby の Struct みたいな。
あれ嫌いな人おるのか。俺も好きじゃないが。純粋に Haskell と同じ文法だったら良かったのにね。
アレはキモいね。素直に ?! で良いと思う。というか、Python は英語圏の人も納得はできないだろ、っていう文法が多くないか？
というのは同意する。ただ、書くときにそうは思わない。例えば、with 構文は Ruby の方がブロックを抜けたらクローズするという方針のが良いと思う。
Sランク：ポテトフライ BIGカツ うまい棒コーンポタージュ味
Aランク：キャベツ太郎 うまい棒なっとう味 ヨーグレット 焼き肉さん太郎
Bランク：たらたらしてんじゃねーよ カットよっちゃん チョコバット
最強格。こいつらだけで300円分組んだグッドスタッフは強すぎるので、
類似商品のポテトスナックの販売終了はDAGASHIERに衝撃を与えたが、まだこいつがいる。
駄菓子界のガブリアス（後述）に比べると汎用性は低いが、エースはこいつ。
なんだこいつ、もはや本物のカツ。いや、カツの衣。
男の子ならみんな大好き衣。
これをおかずにご飯3杯いける。
うまい棒ブランドのコストパフォーマンスの高さがチート。
どんなデッキにも刺さる。
最後の10円〜30円をこいつにするだけで環境トップクラスの力を得る。
Sランクほどではないが充分強い。
全然キャベツの味がしない。しないが、みんな大好きなスナック菓子の味だ。
次回作ではスナックメタの系統が実装されることを祈るが、難しいだろう。
若干の酸味とキャベツを冠するネーミングのせいでSランクを逃した。
あ？なんだ？文句あっか？
Sランクにしてやってもいいんだぞ。それくらいのうまさだ。
こいつの強さに気付かないうちは三流DAGASHIERよ。
スナック菓子全盛の環境において堂々のAランク入りを果たした甘味。
ラムネよりも口当たりが良く、デッキのスパイスになってくれる。甘味なのに。
包装もスナック菓子にはない見た目をしており、
こいつ中心のファンデッキを組んでもそれなりに戦える。
Bランクか迷ったが、焼き肉というネーミングが男の子にぶっ刺さるためAランク入り。
そのため一部界隈でカルト的な人気を誇るが、実力は名前負け感がある。
やはりスナック菓子環境に入り込むには尖った性能でなければ難しい。
たらたらと同門。
トップリーグであるボーイズリーグで実力を発揮しきれないところがマイナス。
今回は省いたが、酢だこさん太郎とのコンビネーションがいろんな意味で有名。
甘味が刺さりにくい環境において、かなり頑張ってくれているほう。
シェアや交換前提のルールでは一気にトップクラスになる実力を秘めている。
お湯が使えないルールだとゴミというルールに左右されすぎなやつ。
だが最近成長が著しいリモートルールではこいつが環境を席巻している。
１－１ 根性を上げるとスタミナの消費量が減る。ただし減る量が大きく変わるのは４００まで。３００～４００はスタミナ１と根性１が相互互換ぐらい。
１－２ 賢さの主な効能はスキル発動率とかかり率。これも上げる効率がいいのは４００まで。４００を８００にしても賢さ判定通れば発動可能なスキル１０個持ってるときに８個発動が９個発動になる程度の差しかない。３００だと６個発動ぐらいなので４００までは上げる意味あり。
２－１ レースボーナスを34%まで上げると育成目標レース１位時の＋３が＋４に変わる。それプラスでURAの勝利時や通常レースの勝利時にもボーナスが入るので全部足すとそこそこの差になる。
２－２ ただし狙いすぎると増えたスキルptを使い切れないので場合によっては諦める。
３－１ 書いてある効果（「わずかに」「速度が上がる」など）が同じでも発動条件が厳しいほど効果時間が伸びる
３－２ ただしスタミナ系スキルについては持続時間が存在せず一瞬で処理が行われるので、発動条件が厳しいスキルほど弱くなる
３－３ また、スタミナスキルの場合は序盤に発動しすぎるとスタミナ溢れが起きてしまうし、後半すぎるとデバフに対する保険にしかならない（ラストスパート速度計算時のスタミナ残量計算に入らない）ので注意
1986年に出版された『任天堂のファミコン戦略』という本が手元にあったので読み返してみたら、以下のような記述があった。
・ファミコンのCPUは任天堂とリコーそれぞれ5名ずつだして10名のプロジェクトチームを作り開発した。
・当時のリコーのスタッフ曰く、任天堂から「ゲームウォッチがピークに来ておりアーケードも落ちていくと予想されるので、新しい製品を作りたい」と昭和57年の夏に声をかけられた。
・開発費は億に達したと言われている。
・リコーの窓口となった浅川俊文は「任天堂には泣かされました。ゲーム機とは言え立派なコンピュータ。その半導体チップを2000円以内で押さえろというんですからね」と語っている。
・それに対し任天堂は2年で最低300万個生産すると保障し、無茶な要求を飲ませた。
・昭和58年春に6502互換CPUの採用が決まった。(ファミコン発売はその年の7月)
・リコーが半導体の生産に参入したのは昭和56年5月。自社のカメラや事務機向けで、余剰分を外販する腹積りだった。
・しかし工場を作ったものの外販先はなく、実績が無かったので一年目は外販ゼロだった。その後アタリ、コモドールジャパンに外販したが業績は良く無かった。
・そこに「300万個は保証するから」という任天堂の山内社長の一声で提携を決断した。
・現在(出版当時)リコーは任天堂への独占供給の代わりに、ファミコン用CPU/PPUの外販は任天堂の許可が必要な契約になっている。
数々の解析によりその正体は遂に解き明かされました。
根性を上げると何が上がるか？ → ラストスパートの速度が上がる
これ自体は間違っていませんでした。むしろ根性の効果をシンプルに言うならこれしかないほど正しかったです。ﾊﾞｸｼﾝﾊﾞｸｼｰﾝ
ただしその過程はやや複雑ですので、まずはラストスパートの仕組みについて説明させていただきます。
最終コーナーを抜けた辺りでウマ娘はラストスパートに入るのはご存知でしょうが、このタイミングとそこからの加速はステータスで決定します。
育てたウマ娘によってラストスパートが始まるのが遅かったり早かったりするのは単なるカメラワークによる演出ではありません。
ウマ娘はラストスパートに入るといよいよ猛烈な勢いで速度を上げていき、それに伴いスタミナは急激に減少していきます。
「ウマ娘はラストスパートで全力を出しすぎると途中でスタミナが切れると判断した場合、スタミナが途中で切れないギリギリの加速でラストスパートを駆け抜けます」。
つまり、ラストスパートにおける速度はウマ娘がそれまでに残すことが出来たスタミナに依存するということです。
さて、カンのいい人は話の流れがもう見えてきていると思います。
根性を上げると、スタミナ消費量が減少し、結果的にラストスパートに多くのスタミナを残すことが出来るようになります。
これはウマ娘のスタミナ計算が「（スタミナ＋回復スキル）*補正値A/（補正値B*根性)」のような形になっているということです。
つまり、根性が低すぎるとスタミナをいくら上げてもスタミナ不足に陥りラストスパートになる頃にはバテてしまうということです。
全身全霊最強伝説から分かるように、ウマ娘は結局の所ラストスパートを最も速い速度で駆け抜けられるかのゲームです。
その際に重要なのがスピードであり、ボトルネックとなるのがスタミナであり、そのボトルネックの狭まりを抑えるのが根性ということなのです。
スタミナの効果は最高速を維持するものと考えられがちですが、ゲームシステムに照らし合わせると「ラストスパートで末脚勝負を仕掛ける際に制限がかけられることを回避するもの」と捉えたほうがより正確です。
そして、根性が低いとスタミナを維持することが出来ず、マエストロや好転一息を使って必死にスミタナを底上げすることで結果的にボトルネックが少しは解消されてレースで良い結果が出ていたということです。
とはいえ根性というやや上げにくいステータスを強化する手間を考えればマエストロを取ってしまった方が手っ取り早いという育成論が全く間違っているわけではありません。
ですが育成終了時の根性が３００を下回っているとかであるのならば、流石にそのウマ娘は根性がなさすぎると言わざるを得ません。
とはいえ根性も極端に低いとどうしようもないだけで、ある程度以上になればスタミナとの相互互換なりますので、マエストロを抜いてタンホイザを入れるべきとまでは言えません。
じゃあどうしろっていうんだよと言われても、私が答えを知りたいぐらいですね。
そもそも走行距離が短距離であればスタミナはパワー育成のオマケの４００根性もURA優勝ボーナス等をかき集めての２２０とかでも十分っぽいですし……。
もちろん長距離ともなれば根性とスタミナの両方を上げていきたいですが、やりすぎるとスピードパワーを上げきれずに今度は増やしすぎたスタミナが使いきれないという事になりますのでマエストロ系で上手くお茶を濁してトレーニングの時間を稼ぎたい……うーん……うーん……
いやーウマ娘って奥が深いですねー
1. エクスプローラーがない
windowsユーザーの使い慣れたエクスプローラが当然ながらMacにはない。
この部分が使いにくいOSはぶっちゃけデスクトップOSとして使いにくくIPADと変わらない。アプリを使うためだけのOS
2. MPC-BEがない
VLCなどLinuxと共通の使いにくいアプリはMacにも有るのだろうが圧倒的に劣るし不便
3. USBにデータコピーしてWinPCで見ると変なファイルがくっついてくる。
互換モードみたいなのを作って、ゴミデータが付随しないようアップデートしないAppleが理解できない。
4. SSDの容量アップが高額。
IPADやモバイル端末はともかく、MACノートPCやIMACなら安価大容量の2.5型SSDで1TB標準搭載が安価に可能なはず。
そもそも夜間に自動化するような業務がなくなるのがRPAじゃねえの
記録しているExcelから業務イントラに入力させる処理とかアホらしい
たいていは業務イントラ用のIE8互換がネックになって動かねえし
間抜けかよ
大体の場合において「bashが欲しい」という人はbashだけではなくgrepやawkやその他諸々のgnu ツールもまとめて欲しているが、それらを合わせてもwindows上で使うPowershellには機能レベルで遠く及ばないし、windows上のbash単体はLinux上のPowershell単体にも劣る。
Powershellでは、「文字列しか通さない古いパイプを通して文字列を切り貼りして受け渡しながら処理をする」なんて面倒なことはない。
bash+gnuツールだと別コマンドで文字列切り貼りしなきゃ取得できないメタデータも、Powershellならパイプでオブジェクトを渡せるから始めからオブジェクトのプロパティとして付いてくる場合が殆どだ。
windows上なら.net経由でシステムの様々な部分へのアクセスも可能だし、COMObject経由でofficeソフトそのものを直接操作もできる。
サードパーティーのモジュールで無理矢理データを弄るんじゃなくて実際にofficeファイルを吐くプログラムそのものをPowershellから操作できる。
なので、Powershellの記事によく付く「こんなのよりbash(+gnuツール)使いたい」ってのは「LinuxでPowershell使いたい」って言ってるようなもんだって分かって欲しい。
windows上においてはbashはPowershellの肩代わりは出来ない。
少し前からLinux上でPowershell動くようになったけど、LinuxユーザがPowershell一から学ぶ価値あるかと言われると、はっきり言って「あんまり無いかな」とは思う。
azure関連のコマンドモジュールがPowershellしかないヤツもまだあるみたいだから、azure触るためだけにwindows用意しなきゃならない事態を防ぐ程度の意味合いしかないような気はする。
そういうモジュールがLinux上のPowershellに対応してんのか知らんけど。
WSLでLinuxが丸々windowsに取り込まれたおかげでカジュアルなwindows上のbash需要も殆どは満たせる時代になったのは良いことだ。
別にPowershellのことを詳しく調べろとは言わないが、bashじゃwindows上のPowershellの肩代わりは出来ないって事だけは覚えておいて欲しい。
我が家は明治期に興隆した商家で、現在も大枠を考えればモノやコトを売ることで生計をなしている。
いわゆる華族であったが、興隆の経過で江戸期以前の地主や武家などと婚姻を経て結びついており、家系図を遡れば皇室とも血筋上の繋がりがあると解釈ができる。
さて、そんな家に生まれた筆者だが正直に言えば高校生くらいまで我が家がそんな家だとは気付いておらず、多少なりとも大きな家に住めている理由として両親や祖父母も「ご先祖様が努力の人だったから」と言っていたので、現在の我が家はそこまでお金持ちではなくご先祖様が増やした資産の恩恵を受けているのだ程度にしか思っていなかった。ご先祖様すげぇなと。
実際、筆者自身の子供の頃の夢はプロアーチャーであったので全く家業を意識していなかった。
我が家はなんか他の家と違うぞ？と気付き始めたのは高校生になった時期で、父や祖父に連れられて社会科見学のような小旅行を頻繁にやるようになってからだった。
自動車工場や造船所、食品工場、アパレル工場、精密機器工場、製紙工場など工業系を中心になぜか見学に連れられ、その工場の担当者らしき壮年の男性から説明を聞くということを頻繁にさせられた。
今思い出せば、父や祖父はそのくらいの時期から「AはBから生産されていて流通として……」のような話をよくしてくれるようになっていた。
社会科見学のような小旅行は面白かったが、なぜ急にそんなことをやるようになったのかという疑問は晴れなかった。まさかそれが後継者教育の一環だったとは。
自分自身の興味と祖父の勧めもあり、大学ではアーチェリーを続けつつもロジスティクスを中心に学ばせてもらい、継続されていた社会科見学が非常に研究へ役立つようになっていた。
そして我が家の歴史を完全に知ったのは大学3年生の正月に「就職はどうするのか？」と言われた際に「参考になるかはわからないが我が家の家業を説明しようか」のように教えられてからだった。
遡れば初代が江戸期に商家として暖簾分けを受け、現在まで続く家業の基盤を明治期に作ることができたとのこと。そこから登場する人名は歴史の授業で習うような人々であり、まるで実感のなかった筆者は驚愕するしかなかった。
そんな家の子息である筆者が普段何をしているのか？と言えば、某物流企業から某商社を経て、現在は父から「そろそろ戻ってこい」と言われ、法人化している我が家の持ち企業へ務めさせていただいている。
筆者の専攻がロジスティクスなので新社会人の頃から数理的に物流を計算するのが主な仕事で、笑ってしまうかも知れないが何処へ行くにもCASIOの関数電卓をポケットへ入れている。現在の関数電卓はソーラーパネル電池で駆動するのでスマホなんかよりもよっぽど信頼度が高い。
弊社が集めたデータや取引先からロジスティクスに関するデータを貰い、それを数理的に損益分岐点とのその確率をはじき出すというものだが、概算ではなく精密に計算する際はコンピューターに詳しい増田の皆様にも馴染み深いであろうAWSやさくらを利用している。
ちなみに筆者のスマホはAndroid。iPhoneにはまともなターミナルがないので、ふと出先で大きな計算リソースが必要になったときAWSへSSHしにくい。まぁノートPC使えよって話だが。
もちろん計算するだけでなく、創作物でイメージされやすいであろう会食などで人脈交流をしたりもするが、実際のところ筆者の世代ともなるとLINEやZoom、Slackなどで友人たちと交流している頻度のほうが多い。
正直LINEやZoomは昨今の流れもあり使いたくないのだが友人たちは経営学部卒などの文系が多いので、どうもセキュアなコミュニケーションツール活用が上手く行かない。
可能ならば弊社で利用しているオフィススイートもMicrosoft office 365やGoogle Workspaceへ移行したいのだが、一部の従業員の皆様の反発から上手く行ってない。後継者といっても実務へ強権を奮えるほど実力はないのだ。筆者の管轄の研究グループは即座にSlackを導入できたり出来たのに。う〜む……。
流れのまま愚痴を言えば、例えば総務などはミドル〜ハイエンド性能なChromebookで十分じゃないか？社内ツールもいつまでJavaベースのを使っているのか。HTML5ベースに移行してしまえば互換性の問題でWindows使い続ける理由もないんだが。いまだ動いてる骨董品メインフレームをそろそろ引退させてあげようよ。
父は「実務に口を出すべきでない」と言うが、多少筆者の趣味も入ってはいるものの環境を整えるのも我々の役目ではないだろうか。
強権を奮って一気にモダンなコンピューティング環境にしたい。営業にも今のガラケーから最新のGoogle Pixel 5あたりのスマホを配ってあげるのに。
というようなことを青臭く思っているのだが、実際の後継者なんてこんなもんである。実権を握れるまでおとなしくしているしか無い。
従業員の皆様には申し訳ないが、おそらく筆者にはご先祖様ほどの商才は無いんだろう。苦労させてごめんね。
きっかけはLightiningに上げようと色々調べてみたこと。
立ち上げる度にLightingの画面に切り替わって催促されるしｗ。
その中でこれはキツいな、受け入れられないな、と感じたのが下の2つ。
その1 差し込み印刷が出来ない。
Salesforceに限らず古いバージョンで出来てたことが出来なくなるのは
仕方ないのでテストも兼ねて弊社のプログラマーに頼んで作らせてみた。
DBの中身拾ってきてhtmlで整形する、という手法でやってみた。まあ出来るようにはなった。
なんだけどこの程度のことでわざわざプログラマーの手を煩わして
コーディングってのもちと違うよね。簡単に出来ることに手間かけるってのは本末転倒の極み。
おまけにAPI使うには追加費用が必要云々言ってきた。まあそういう価格体系なんだろうけどそもそも使ってた機能が
使えなくなったことが要因なのでこれには不満が残った。
お客様のライセンスでは開発のサポートは出来ません、みたいな連絡も頂いた。
これも正しいんだろうけど、たかが差し込み印刷を開発というのもどうなのかと？
簡単なことをわざわざ「開発」しないと出来ないことがむしろ問題なので。
日本人って帳票沢山使う民族なのでこれ出来なくて困ってる人沢山いるんじゃないかな。
プラグイン作ってるとこは儲かるかもしれないが。
が、なんと現行のナレッジベースとLightingの互換性がないらしい。
サポートに聞いてみると自分でローダー使って移してくださいと。出来ない場合は手で入力してくださいと。
何百件あるのを手で入力って言うのは簡単だけど現実的ではないよね。
が、そもそも同じソフト/サービスで新バージョンに移行するにあたって
あとそもそもローカルでそういう面倒なことやんなくていいのがクラウドのメリットだったはず。
データ自分で移行しなきゃいけないなら他のシステムにいくのと変わらないと、判断し
この時点で決心した。
それと今のライセンス(Professional)ではLightingに上げるとそもそもナレッジベース使えないらしい。
つまり新しいほういくとライセンスを上のグレードに上げる必要がある。
つまり、実質的な値上げなんだけど、どこにも値上げと唄ってない。
こういうやり方、手法を取ったとしたらそれはベンダー側の判断。こっちが決めることじゃないので。
が、いかにも後味悪い。遺恨を残す。なんだかなあと。
何故か怒りは全く湧いてこず一番良い手法を
早く見つけようという気になった。SFのサポートや営業を責めても仕方ないしね。
彼らは彼らの仕事を真面目にやってるだけなんで。実際一生懸命やってくれたし。
で、ZOHOのデモ版登録して色々試してみた。他のも色々見てみたけど
移行が簡単そうだったので。
途中引っかかる点もあったがサポートの力を借りながら全部のデータ無事に移行終了。
こちらで運用開始、そして今に至ってる。弊社はあんまり難しいことやってないからね。
カスタムオブジェクトがいくつかあるぐらい。あとはサブスクリプションの管理の項目がなかったので
予め作っておいた。
UIはそう言われても仕方ないと思う）、だったので中身よく似てる。
直ぐに使えるようになった。ぶっちゃけUIはこっちのほうが良いんじゃないかな。
あとコストの点も大きい。
SFはずっと1人会社の頃から使ってて、会社が大きくなって人数増えてもユーザーは小生一人だけだった。
が、この先新規事業でユーザー増えてくのでその前に移っておいてホント良かったかなと。
10年以上使ってたシステムを移行するの躊躇した時もあったがやってみると
思いの外簡単だった。色々弄ってると今は使ってないテンプレートとか
出てきてああ、こんなことやってたなあと、感慨深かった。
色々あったがSaleforceにはここで改めて礼を言っておこう。
SF/CRM的なサービス今は沢山あるので自分にあったのを選べば良いと思う。
