(來源:Albert Moreno

之前寫過一篇〈初探 Orator ORM〉,有介紹了 Orator ORM 的基礎操作,而此篇文章就專門介紹 Orator ORM 的 seeding 機制,本篇的範例也都延續自〈初探 Orator ORM〉,還沒讀過的朋友請趕快手刀點擊閱讀。


(來源:Thomas Koukas

這篇主題談的並不是《從 A 到 A+》的什麼廉價低配版,並不是

之前寫過一篇〈你的程式是資產還是負債?〉,裡面分享了把程式比喻成負資產的危害,以及如何活化資產的幾種方式,這一篇我想延續「資產」的概念,分享我對正資產程式的成長循環的觀點。

即便我們把手中有活躍客戶(以及收入)的產品視為正資產,但這樣的資產和房地產/股票/存款還是有本質上的不同——產品是不會生利息的,不會就是不會。

那麼要如何實現產品的成長?最直覺不經思考的策略大概會是「靠業務努力衝啊!」這種愚公移山式的努力。

在網路和 app 商店還不存在的年代,當時的軟體產品的確只能靠實體通路與業務,實體通路負責套裝軟體的分銷,業務進行專案型系統的推廣,隨著後續網路、app 商店、雲端等技術的出現,軟體逐漸變成服務——為了解決用戶問題的服務, …


(來源:Joe Dudeck

在幾年以前,我曾經陸續讀到過幾個相似的概念——5S斷捨離、《怦然心動的人生整理魔法》,它們在我心中逐漸建構起一個共同的核心觀念——「物品的價值在於被有效的使用」,這個概念成立的基礎在於人們能掌握的資源是有限的,特別是時間與空間。當一個物件被閒置在某個角落,而那個堆雜物的角落假設佔了一坪的空間,那麼相當於我花了成本相當於市價一坪的錢買了那塊地,上頭卻供奉著僅僅是被歸類於雜物的物件們,他們紮紮實實的佔據了那一坪空間不是嗎?也因此你與家人的走動空間也確實少了那一坪沒錯吧!

前面提到的概念,在個人的階段,如同斷捨離所倡導的,「斷絕不需要的東西;捨去多餘的事物;脫離對物品的執著」,具體的行為如《怦然心動的人生整理魔法》所實踐的——取出那些閒置物件,一件一件思考它對你的意義,如果它不再令你感到「怦然心動」,那麼就謝謝它曾經帶給你的意義與價值,然後就妥善地將它交給回收車,告別彼此展開新的生活。

如果我們把層次拉高到社會的層面,也會發現社會中也有類似的角落,試著回想你家附近是否曾經有過一個小孩不敢進去的公園,又或者是蓋到一半的爛尾樓發生過火災的猛鬼大樓等,這些閒置設施(甚至是嫌惡設施)不論是私有的或公家的,顯然不像個人物件那樣能被輕易的斷捨離,必須採取斷捨離以外的手段,像是「都市更新」與「資產活化」都是常看到的做法,政府藉由推動都市更新,改建老舊建物,不僅提升城市形象,對民眾來說生活品質也有所提升,更有感的可能是區段地價房價的上漲,對政府來說則是經濟活動活絡之後帶來的人口與稅收的增加。資產活化則常見於閒置廠房土地的重建,賦予不動產新的附加價值,帶來經濟上(永豐餘)或文化上(西門紅樓松菸林百貨)的收益。

程式是資產還是負債?


(來源:Edurne Chopeitia

Orator 是 Python 世界內的一套 ORM,介紹 Orator 前先簡單介紹 ORM,ORM 全稱 object-relational mapping,它是協助程式語言操作資料庫的中間人,ORM 把資料庫的 table 對應到程式內的 class,而 table 內的一筆紀錄則是對應到程式內的物件,紀錄內的欄位則是對應到物件的屬性,除了資料的對應外,其他增刪改動作也都有 ORM API 函式可以呼叫,如果 table 是有關聯性的,在程式內也可以設定 class 間的關聯性。

ORM 把資料庫的操作物件化後,在程式專案內就可以不用寫 SQL,可以以操作一般物件的方式去對待資料庫,有了 ORM 的基礎觀念之後,再引入 MVC 架構的 model 角色——model 是抽象化的概念,具 …


(來源:Lars Kienle

這篇是某個晚上試玩 Strapi 這套 headless CMS 的心得,主要是談 Strapi 和 headless CMS 帶來的變革,不太會談到具體的操作過程。

先談談 headless CMS。

Headless CMS

Headless CMS 是前後端分離概念下的產物,headless CMS 可以簡單的理解為剝去前端的 CMS,headless CMS 以 API 的方式(通常是 RESTful API 或 GraphQL) 供應前端內容,前端(通常是 AureliaSvelte、Vue、React、Angular)也透過 API 與 headless CMS 溝通,取得內容呈現,或發送內容回 headless CMS。

在上面的前後端分離的架構下,headless CMS 必須具備幾項特性:

  1. 管理內容的能 …


(來源:AaronJOlson

Python 的版本

Python 進入 3.x 的時代也好幾年了,但至今 Python 2.7.x 即便已經不再維護,它還是以某種殭屍的型態存活在各個陳年專案上,對一個沒有舊包袱的新專案來說,Python 3.x 的 x 就必須是在開立專案時要考慮的問題,在 Python 的網站上有 Python 各版本目前的生命週期表


商米 T2 MINI(來源:商米)

最近我們公司透過經銷商進了一台商米 T2 MINI,商米是小米生態鏈的公司之一,專門製作以 Android 為基礎的 POS 主機/自助機以及週邊設備等,Android 的商用設備對一般人來說可能比較少見,開箱文更是幾乎不見於網路,這篇文章分享我們剛入手後試玩幾個小時的一點心得,也站在商業應用的角度談談與一般家用平板的設計差異。

商米 SUNMI


(來源:Kristian Strand

最近我們在公司內啟動了一個新的計劃 — — 鼓勵所有同仁建立自己的網誌,在上面分享自己工作上的心得筆記,或是自己個人的 side project,抑或是更廣泛的資訊產業觀察、應用等的文章,在鼓勵同仁寫作的同時,在公司的網誌上我們也打算曝光在更多的平台上,因此一輪的寫作平台的比較就開始了。

寫作平台的抉擇

在挑選曝光平台的抉擇上,因為人力畢竟是有限的,實務上不可能在每個平台都曝光,從 20 年前的 Blogger 到現在當紅的 Medium 都評估一輪後,再回到我們想增加公司文章曝光的初衷,我們先把寫作平台分成兩類:

  • 有編輯經營的,也就是在平台首頁有編輯(不論是人腦還是電腦)選文的。這類的平台包括 Medium、探路客 Timelog、方格子 Vocus、Matters、Wreadit、uMedia 等。
  • 沒有編輯經營的,也就是平台首頁僅作為介紹平台功能之用,沒有編輯選文的。這類的平台大約都較早期,包括 WordPress.com、Blogger、Tumblr 等。

至於痞客邦和隨意窩 Xuite,雖然他們也有編輯選文,不過一開始就不在考慮的名單內,因為那版面實在是不忍直視⋯⋯。

站在公司網誌的立場,我們比較偏好有編輯的平台,這類平台通常也具備某種程度的社交元素,讀者可以對你的文章表示喜歡(讚/星星/愛心)以及訂閱你的文章的功能,訂閱後有新文章刊出還會出現在讀者的首頁上,有機會讓我們的文章得到更好的傳播性。反之沒有編輯的平台就只能視為「網誌代管平台」,和自架差不多,傳播的管道只有粉絲團和 Google 的自然/付費流量。

以有/無編輯來做完初步的篩選之後,下一輪我們來比較他們的單篇文章閱讀介面,下文都會站在一個公司網誌的觀點來評論各家平台的特點。

Medium

Leon

產品開發的「思想的巨人、行動的侏儒」。https://leonh.space/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store