タグ

2019年10月3日のブックマーク (15件)

  • Amazon RDS の PostgreSQL DB エンジンのアップグレード - Amazon Relational Database Service

    OS の更新 - では、Amazon RDS は、セキュリティの修正や OS の変更を適用するために、データベースの基になるオペレーティングシステムの更新が必要になる場合があります。RDS コンソール、AWS Command Line Interface (AWS CLI)、または RDS API を使用して、Amazon RDS に OS の更新を適用するタイミングを指定できます。OS 更新接続の詳細については、「DB インスタンスのアップデートを適用する」を参照してください データベースエンジンの更新 - Amazon RDS が新バージョンのデータベースエンジンをサポートすると、データベースをその新バージョンにアップグレードできます。 このコンテキストのデータベースとは、RDS for PostgreSQL DB インスタンスまたはマルチ AZ DB クラスターです。 Postgre

  • Apex,Visualforce 動的にカスタム項目を取得する

    いつも忘れてしまうので書いとく。 参考:sobjectを利用したカスタムオブジェクト項目取得サンプル やりたいこと Visualforceページ等では、URLパラメータに連動して、様々なデータの取得を行うことが多いのですが、その際に動的に取得したいデータを変えたいことがあります。それもこれも、過去のデータ構造のせいではあるのですがそこは致し方ないので、それを乗り越えるための実装を考えることになる。(ちなみにその過去の遺産を作ったのも自分であり、十字架を背負って生きている) 例えば、弊社のある項目では、特定期間の売上金額を 2019_01__c 2019_02__c みたいなカスタム項目にまとめており、これをURLが /apex/myVisualforcePage?yearmonth=2019_01 の時に取得するようなことを検討することになる。 まずはオブジェクトリストを取得する ここはそ

    Apex,Visualforce 動的にカスタム項目を取得する
  • Outlook REST API 開発 (Outlook.com 対応も)

  • Salesforce → Slackに通知を送る(プロセスビルダー & Apex)

    Slackに通知を送りたいという事がそれなりにあると思う。 Slackは公式にSalesforceと連携する旨を発表しているし、今後利便性は上がっていくだろう。 とは言え、カスタムの通知を投げたいという事がある。そんな時にどうするかという話。 やっていることは以下の2つを参考にしていますが、テストでこけたりしたので若干改編しています。 A:SalesforceSlack通知をオープンソースで公開しました B:Slack and Salesforce Integration ToDo SlackにWebhookを設定する ApexClassを作る プロセスビルダーで起動条件を設定する テストしてリリース 1はリンクAを参照のこと ApexClassはこちらを参照 プロセスビルダーについてもリンクAを参照 あとはテストしてリリースです。簡単!

    Salesforce → Slackに通知を送る(プロセスビルダー & Apex)
  • Salesforce→Slack通知をオープンソースで公開しました - Qiita

    こんにちは。co-meetingの木村です。 弊社ではSalesforceSlackの連携はZapierで実現しているんですが、Zapierはオブジェクトの新規作成にしか対応していなかったり、15分おきだったり、Salesforceは有償のみだったりでちょっといまいちなのです。 というわけで、以下の方針でSalesforceからSlackへのリアルタイム通知を作ってみました。 Slack通知オブジェクトを作成し、Apexトリガで作成時にSlackに通知するよう設定。 プロセスビルダーで何か通知したいことを監視して、Slack通知オブジェクトを作成する。 通知の設定はプロセスビルダーでできるので開発者じゃなくても簡単にできますし、プロセスビルダーでできることはなんでもできるので、けっこういろいろな通知ができます。 ソースもGithubで公開して、未管理パッケージのURLも提供していますので

    Salesforce→Slack通知をオープンソースで公開しました - Qiita
  • Help And Training Community

    Loading×Sorry to interruptCSS ErrorRefresh

  • SQLのインデックスとそのチューニングについてのオンラインブック

    開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQLOracleSQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 Db2 (LUW)U

    SQLのインデックスとそのチューニングについてのオンラインブック
  • pg_hint_plan (PostgreSQL 実行計画制御ツール)

    ヒント句一覧 http://pghintplan.osdn.jp/hint_list-ja.html (上記ページは文書作成時点では v1.1 の内容です) ◆ 実行例 ここから実際にヒントを与えて実行計画を変更する例を示します。この例ではヒントを指定することでプランナの計画した不適切な実行計画よりも適切な実行計画を指定しています。 検証例のサンプルデータは以下の通り pgbench コマンドで作成しています。 $ pgbench -U postgres -i -s 10 db1 creating tables... ... $ psql db1 db1=# VACUUM ANALYZE; VACUUM pgnemch コマンドで作成された pgbench_accounts テーブル、pgbench_branches テーブルに対して結合とソート操作を行うクエリの実行計画を検証します。

    pg_hint_plan (PostgreSQL 実行計画制御ツール)
  • 社内無線LAN環境改善のためにやったこと (2019/Summer) - astamuse Lab

    こんにちは。並河(@namikawa)です。 すっかり秋の足音が聞こえてまいりました。秋といえば欲の秋。ラーメンの秋です。 会社では最近新しい方がたくさん入社してきてくれていて嬉しい限りで、エンジニアやデザイナーも増えてきています。 面接をしていても「社内の雰囲気ってどんな感じなんですか〜?」なんて聞かれることも多いので、ちょっと最近入社されたエンジニアの方のデスクを紹介してみようと思います。 弊社では、入社される方全員に、業務で使うマシンの希望を伺っているのですが、エンジニア・デザイナーは MacBook Pro を選択される方がほとんどです。エンジニアの場合はそれに 32 インチの 4K モニターを一緒に貸与することが多く、デザイナーは EIZO のモニター(27インチ、2枚等)とか希望を伺いながら決める感じです。 参考までに、池田さんが書いてくれた、4Kモニターを使っているレポート

    社内無線LAN環境改善のためにやったこと (2019/Summer) - astamuse Lab
  • KindleFireにGooglePlayを入れなくてもAuroraStoreでカバーできる - W&R : Jazzと読書の日々

    数多ある野良アプリ。実際インストールして安全なのかどうか、保証がありません。ちょっと怖いですよね。そこでアプリ開発者が集まり切磋琢磨しているXDAを見てみました。 開発中のベータ版があったり、完成してもGooglePlayに登録しないインディーズ系のアプリが集まっています。開発者が互いをチェックし良質なアプリを目指している。そしてなぜかGooglePlay互換アプリが開発中でした。KindleFire以外でも必要なのかな。 XDA Labs Silkブラウザでアクセスしてください。右上のアイコン・マークからサインアップ。GoogleのアカウントでXDAのメンバーになれます。会費は取られません。前回のYouTube Vancedもここから生まれていました。ソースが公開され、スレッドで討議されています。 XDA Labs Support independent Android developm

    KindleFireにGooglePlayを入れなくてもAuroraStoreでカバーできる - W&R : Jazzと読書の日々
  • ジャバの異常な愛情 またはSpringはいかにしてモダンであることを止めて時代遅れになったのか - Qiita

    Spring以前 RPC 業務で使うシステムはサーバー間で連携することが多い。2019年現在ではREST apiに対してjsonやprotocolbufferで呼び出す事が当たり前のように行われているが、まだjsonも発見されていない時代はもっと複雑な仕組みが取られていた1。異機種間でやりとりするためのCORBAや、機種に依存しないデータプロトコルのASN.1なども利用されていたが、仕様は複雑でそれぞれをハンドリングするライブラリは有償で売られ、ベンダーからサポートを受けながら使用するようなものだった。 RMI Javaの世界ではJava同士でやりとりするためのRMIが定義され、比較的に楽にRPCできるようになった2。とはいえhttpでrestをコールすることに比べたらアホみたいな複雑さである。 https://docs.oracle.com/javase/jp/1.3/guide/rmi

    ジャバの異常な愛情 またはSpringはいかにしてモダンであることを止めて時代遅れになったのか - Qiita
  • 「弱さ」をめぐる旅のはじまり|鈴木悠平|note

    「適応障害ですかね。」 「そう思います。」 平日の夜、職場から徒歩5分のクリニックで、最近知り合った医師の先生とそう話したのは、今の会社で働きだして5年目の夏のことだった。 「仕事も人も、好きなんですよね。嫌な理由ないんですけど。でもしんどいんですよね。」 風邪をひいているわけでもないのにやたらと咳が出る。オフィスに向かうだけでドッと疲れる。ミーティング前には動悸がする。言葉以上に身体は正直だ。 適応障害というのは、特定のストレス要因に反応して心身の症状が起こる疾患である。受診の場に至ってなお「別に仕事が嫌なわけじゃなくて」と防衛線を張る僕に対して、「あなた、そろそろ限界ですよー」と身体が言っているのだ。 「俺もついにビョーキになったか」という、不思議な安堵と納得。「明日はどういう報告と相談をしようか」という、極めて実務的な対応方針の思案。そういう色々が混ぜこぜに頭を巡りつつも、先生に診断

    「弱さ」をめぐる旅のはじまり|鈴木悠平|note
  • 論理的に話す人の落とし穴 立て板に水が不快な理由 | NIKKEIリスキリング

    今回は、弱気な人でもうまくいく「問いかけ交渉」を取り上げます。自分は営業や販売職ではないから、交渉ごとは関係ないと思っている人がいるかもしれません。しかし、職場でも家庭でも交渉する場面はたくさんあるものです。私たちは日々、交渉を重ねながら暮らしたり働いたりしているといっても、過言ではありません。 交渉で失敗を犯しやすい人には、大きく分けて3つのパターンがあると思います。「交渉が苦手」だとか、「交渉ごとの矢面に立つのは嫌だ」と考える人はこれらのパターンのいずれかに当てはまっている可能性があります。 第1の類型は摩擦を恐れる「なあなあタイプ」です。自信がなく、自己主張が苦手。リスクをおそれ、相手との衝突を避ける。そういう人です。このタイプは相手が非常識な要求をしてきても、相手のいいなりになってしまいがちです。 第2のパターンは言葉で威圧する「戦闘家タイプ」。交渉は説教や教育ではありません。まし

    論理的に話す人の落とし穴 立て板に水が不快な理由 | NIKKEIリスキリング
  • あの“とんでも社員”を解雇させたい!

    どうすれば問題社員をクビにできるのか 神崎は大塚マネージャをオフィスの一番奥の会議室に呼び出して、中島係長からの電話の内容を伝えた。大塚は、神崎の報告を聞くなり、ほえた。 大塚 「何だとぉ! もう勘弁ならん! 柏木はクビだ、クビ!」 神崎には大塚の感情抑制メーターの針がレッドゾーンまで振り切れたのが見えた。やはり、一番奥の会議室に呼び出したのは正解だった。大塚をなだめるのはもう不可能だろう。 神崎自身も、柏木の言動によるシワ寄せがクライアントにまでおよぶようになってしまっては、柏木をチームに留めておく方がリスキーだと思っていた。ただ同時に、素朴なひっかかりもないではなかった。 神崎 「大塚さん、ことここに至っては僕も柏木を弁護するつもりはないですけど、でも、そんなに簡単にクビにできるもんですかね。何か、社員を解雇するのは法的に難しい、みたいな話を聞いたことがあるんですけど」 大塚 「そりゃ

    あの“とんでも社員”を解雇させたい!
  • 技術者(もしくは技術者出身のマネージャー)の殺し方

    いわずもなタイトルは釣りです。たぶん、過去に色んな技術者やメディア等で議論されてきたのではないかと思う。自身が今の職場で久しぶりに清々しいくらいに経験しているので、備忘録として状況をできるだけ冷静に書き記すものである。参考になりえるとしたら”現職の状況がヤバイんだけど、どうやって現状打破を目論見ながら最悪のシナリオを想定した逃げ道も確保するか”といったところの考え方くらいかもしれない。それ以上もそれ以下も意味はない。 背景業界についてはあえてぼやかすが、歴史が長い業界だ。自身が参画したのははじめての業界だ。いろいろと勝手がわからないことはある。業界の歴史が長いからということではないと思うが、業務フローやプロセスが古臭い。逆に私達技術者の活躍の伸び代がまだまだある業界でもあると言える。自社事業(サービス)を持つベンチャーだ。 技術的なことを包括的に担当してほしいということだった。結果的に(他

    技術者(もしくは技術者出身のマネージャー)の殺し方