Sherry L
[LeetCode] SQL Study Plan_Day 2

#1873 Calculate Special Bonus

Notes

CASE
    WHEN condition1 THEN result1
    WHEN condition2 THEN result2
    WHEN conditionN THEN resultN
    ELSE result
END;
SELECT CustomerName, City, Country
FROM Customers
ORDER BY
(CASE
    WHEN City IS NULL THEN Country
    ELSE City
END);
  • Usage of NOT LIKE with Wildcards in SQL:
    In this case we are looking for words that do not start with a ‘M.’ Therefore we should use ‘M%’ with the NOT LIKE to include them.

SQL Wildcards

  • Usage of remainders:
    In this case we are looking for odd numbers, which means it has a remainder of 1 if divided by 2. There are several ways to indicate a remainder statement:
    1. MOD statement:
      SELECT MOD(9, 2);   // 1, odd number
      
    2. x % y
      SELECT MOD(employee_id, 2) != 0
      
[LeetCode] Problem Solving Pattern_Frequency Counter

I am currently studying the Udemy course JavaScript Algorithms and Data Structures Masterclass and want to jot down some notes. This post is dedicated to the problem solving pattern - Frequency Counters.

Scenarios

In some problem sets we can see questions like “how many times has a, b, c occurred,” “find the most frequently appeared element” popping up. And that is the sign of frequency counters.

Key Takeaways

  • Use objects or sets to collect values/frequencies of values
  • Try to avoid nested loops or O(N^2) operations with arrays/strings

Basics

Here is a Code snippet of a basic function same(), and validAnagram().

Exercise 1, Exercise 2

[Work] 解決問題的過程

前言

「解決問題」可以說是工程師的日常,例如 需求下來了,準備實作功能時,如何去規劃?知道程式碼有 bug,要找出它並修好,使服務正常上線、服務 performance 不佳,想找出徵節點並加以改善等等。

雖然每天都在重複以上情境,卻沒留下什麼紀錄。我想藉由最近一次解決問題的經驗,來剖析自己面對問題時的思考、與後續採取動作的流程,做一次詳細的紀錄。

[Work] 前後端分工的觀察

前言

學生時期做過前後端協作的專案,但因缺乏討論,後端寫 API 時前端還在切元件,因此等到要串接時,只能對後端寫的回傳格式照單全收,又或者修修改改,要後端配合前端渲染方便所需的格式而組出奇怪的資料結構,並沒有一個討論出一個格式或職責分工的標準。後端工程師工作至今快半年,透過實際解決客戶需求、和前端工程師合作開發,以及接受技術主管的任務分派,也體驗到實務上的情境、對應的做法確實與學生時期大大不同,以此篇紀錄這陣子協作的心得與疑問。

這個主題會分兩篇,一篇是我在工作上的觀察與疑問,另一篇收集網路上的說法,看看大家對前後端分工、商業邏輯的配置是如何分別。

情境

由於公司產品(ioT)近期正經歷調整的階段,慢慢轉為多個微服務的架構,因此我也獲得自己 own 一個 service 的學習機會,在從零打造 service API 到與前端工程師協作、到 review 產品功能定義到與 UI/UX 設計師討論的過程中,也經歷了不少「協調」與「配合」。

[Tutorial] Hexo Blog_Auomori 架設

先附上 我的 Hexo,之後裡面的內容會跟 Medium 做出區別~

開始工作後經歷了一段手忙腳亂的適應期,最近總算是能夠重啟自學習慣,但對於一些在工作上學到的、片段式的筆記、或刷題紀錄,很難更新在 Medium 上,因為它給我的感覺比較正式,不寫完整點、不潤稿的話,沒辦法隨意發佈。

所以我開始搜尋替代方案:希望能夠快速撰寫、推出文章,好管理,可自訂 domain name、對於內容樣式有更大的掌控權…,看來看去 Hexo-blog 滿符合我的需求:

  • 使用 Node.js
  • 可以快速建立
  • 使用 Markdown 語法
  • 檔案好管理
  • Build 和 deploy 也很容易且自動化

雖然網路上很多教學的資源,但我使用的這個佈景主題目前還沒什麼人在討論,在建立的過程中踩了不少雷,所以乾脆整理成一份分享,希望透過這篇讓還在對 Hexo 猶豫的朋友們無痛入坑。