2016 / 10 / 30 搬機房, 有幾件事沒有做好, 記錄一下:
1. Firewall 沒設定好, 下次要一中兩個人一起設定.
2. 有一個客戶的 DNS 等了一整天才生效, 要檢查所有網站的 TTL 和 Refresh 時間, 最好都在一個小時以內.
3. Email 主機: 有些客戶原來是用 msa.hinet.net 這個 SMTP, 搬到非 Hinet 的機房後就不能寄信了.
4. 某一個客戶的 DNS 沒改好, 因為在自已的 DNS Server 上面看到有記錄, 就誤判是我們代管的, 應該要用 Hinet 或 Google 來確認 NS Record 為何. 已刪除它的 DNS 記錄.
5. 202 的 .8 網路線沒插好, 主機開起來後, 要確認可以從每一個介面 Ping 出去.
6. 新 Firewall , 內部 IP 無法連到 Virtual Server: --> 要由內部 IP 連線到 Virtual Server 測試. 最好是在 hosts 上面都有 127.0.0.1 的設定.
7. 最好不要在下半年換機房, 比較忙, 客戶的活動也比較多.
8. Windows 的 DNS 若是直接修改 DNS 檔案. 因為 SOA 的序號沒有修改, 所以 Client 伺服器要手動重新讀取資料.
9. 要記得改 TWNIC 的 DNS Server設定.
Bike, 2016/11/3 上午 11:05:19
--抓所有的 Table
Select * from INFORMATION_SCHEMA.TABLES
--抓所有的 COLUMNS
Select * from INFORMATION_SCHEMA.COLUMNS
--抓欄位的 Description
select
st.name [Table],
sc.name [Column],
sep.value [Description]
from sys.tables st
inner join sys.columns sc on st.object_id = sc.object_id
left join sys.extended_properties sep on st.object_id = sep.major_id
and sc.column_id = sep.minor_id
and sep.name = 'MS_Description'
where st.name = 'TableName'
and sc.name = 'ColumnName'
--修改欄位的 Description.
EXEC sp_updateextendedproperty
@name = N'MS_Description', @value = 'Your description',
@level0type = N'Schema', @level0name = 'dbo',
@level1type = N'Table', @level1name = 'TableName',
@level2type = N'Column', @level2name = 'Name';
EXEC sp_addextendedproperty
@name = N'MS_Description', @value = 'Code description',
@level0type = N'Schema', @level0name = 'dbo',
@level1type = N'Table', @level1name = 'TableName',
@level2type = N'Column', @level2name = 'ColumnName';
--新增 Table 的 extendedproperty
EXEC sp_addextendedproperty
@name = N'Description', @value = 'Hey, here is TableName description!',
@level0type = N'Schema', @level0name = 'dbo',
@level1type = N'Table', @level1name = 'TableName'
GO
--修改 Table 的 extendedproperty
EXEC sp_updateextendedproperty
@name = N'Description', @value = 'Hey, here is my description! 123',
@level0type = N'Schema', @level0name = 'dbo',
@level1type = N'Table', @level1name = 'TableName'
GO
--讀取 Extended Property
SELECT sys.objects.name AS TableName, ep.name AS PropertyName,
ep.value AS Description
FROM sys.objects
CROSS APPLY fn_listextendedproperty(default,
'SCHEMA', schema_name(schema_id),
'TABLE', name, null, null) ep
WHERE sys.objects.name NOT IN ('sysdiagrams')
ORDER BY sys.objects.name
--讀取 Column 的 Description
SELECT objtype, objname, name, value
FROM fn_listextendedproperty (NULL, 'schema', 'dbo', 'table', 'TableName', 'column', default);
GO
--讀取特定 Table 的 Description
SELECT *
FROM fn_listextendedproperty (NULL, 'schema', 'dbo', 'table', 'TableName', default, default);
GO
--讀取 所有 Table 的 Description
SELECT *
FROM fn_listextendedproperty (NULL, 'schema', 'dbo', 'table', default, default, default);
GO
--新增或修改資料表說明
IF not exists(SELECT * FROM ::fn_listextendedproperty (NULL, 'user', 'dbo', 'table', '資料表名稱', NULL, NULL))
BEGIN
exec sp_addextendedproperty 'MS_Description', '資料表說明', 'user', 'dbo', 'table', '資料表名稱'
END
ELSE
BEGIN
exec sp_updateextendedproperty 'MS_Description', '資料表說明', 'user', 'dbo', 'table', '資料表名稱'
END
--新增或修改欄位說明
IF not exists(SELECT * FROM ::fn_listextendedproperty (NULL, 'user', 'dbo', 'table', '資料表名稱', 'column', '欄位名稱'))
BEGIN
exec sp_addextendedproperty 'MS_Description', '欄位說明', 'user', 'dbo', 'table', '資料表名稱', 'column', '欄位名稱'
END
ELSE
BEGIN
exec sp_updateextendedproperty 'MS_Description', '欄位說明', 'user', 'dbo', 'table', '資料表名稱', 'column', '欄位名稱'
END
Bike, 2016/6/29 下午 04:42:25
用了大概一年半的
git flow(是 git 的一種開發規範) ,最近才開始有一點領會到分散式的精神,
先簡單比較一下,在開發新功能上 集中式與分散式的差別
SVN(集中式):
從 SVN Server Update到最新的版本 ->
開始照著需求修改程式 ->
遇到程式被鎖住請他unlock ->
繼續開發 ->
開發完成把 修改過的程式 commit 到 SVN Server 上
git(分散式): git flow
先從server 上的 repository 拉下最新的版本 到自己的 repository
(這邊很不一樣 git 會有一個主要的repository 然後開發端又有自己的) ->
建立一個新的Branch來作為開發用 ->
開發程式(不會去Server 上確認是有人在改相同的程式) ->
開發完 commit 到自己的local端的 repository ->
送一個合併 Branch 的需求 ->
管理的人做 Code Review 然後把開發的新分支合併
優缺點:
集中式從頭到尾都只有 1 個 repository,確保了所有人的程式都是同一個版本,
如果現在有兩個新的 feature 都要改同一支程式,就必須先後開發的必要,或是
日後做 merge 的動作,但集中式的設計,並不強迫我們做 code review 的動作
,所以要解決 conflict 時會額外耗時也抗拒。
或是我同時要開發兩個新功能,在集中式管理,我們勢必會包一包一起commit,
但在git flow 上就會開兩個 branch,在未來我們更容易了解整個開發歷史。
git flow 使用經驗中,獲得最多的其實是 Code Review 的過程,Code Review
大家會更能接受自己的做法被質疑,從討論中得到更簡易解法,進而改善整個專案
的品質和可維護性,同時可以降低duplicate code 的情況。
更重要的了解 git 後,可以在 github 上面跟全世界的人一起開發(雖然我沒機會到共
同開發其他專案),有更通用的 naming convention,更多解決方案工具。
瞇瞇, 2015/7/25 下午 08:09:54