thảo luận Code trên Mac với Win cái nào sướng hơn?

  • Người tạo chủ đề Người tạo chủ đề bamboo.bamboo
  • Ngày bắt đầu Ngày bắt đầu
không nói cái khác, theo cái ss của bạn thì bạn cũng đồng ý việc nhiều khi phải sửa nginx config đúng không?

mà cái kia không phải là hotfix, fix 1 lần mà 30p thì tôi cũng chịu, cái kia là thằng đó sửa trong code, mỗi lần sửa xong nó sẽ mất tầm 20~30p để cái code đó có hiệu lực thông qua ci/cd, aka nếu nó config (trong code) sai thì phải đợi deploy xong mới biết được, do có n websites cho nên lần deploy đó mất x phát 30p chứ không phải 1 lần là xong, khá nản (đừng hỏi tôi tại sao lại thọt thế, tôi cũng muốn biết).

Sửa thì đúng nhưng còn chuyện nhanh chậm có hiệu lực thì tùy vào tech nữa. SSH thì nhanh quá rồi, chứ còn cái đông kia thì ko nhanh dc.

À thằng này nó xài CI thì tùy vào gói CI.

1 cai CI free thì thương chỉ cho 1 job. CI pro thì có thể tối đa 4 5 job cùng 1 lúc. CI doanh nghiệp có thể custom nhưng $ nhiều.

Nên anh chờ lâu là đúng. Tại tôi thấy deploy 1 app mà 30p thì lâu quá. Deploy n app thì chỉ chạy max dc số maximum job thôi. Còn lại phải chờ.

làm project cty thì nó nhiều bước, nhiều quy trinh.
 
Sửa lần cuối:
À thằng này nó xài CI thì tùy vào gói CI.

1 cai CI free thì thương chỉ cho 1 job. CI pro thì có thể tối đa 4 5 job cùng 1 lúc. CI doanh nghiệp có thể custom nhưng $ nhiều.

Nên anh chờ lâu là đúng. Tại tôi thấy deploy 1 app mà 30p thì lâu quá. Deploy n app thì chỉ chạy max dc số maximum job thôi. Còn lại phải chờ.

làm project cty thì nó nhiều bước, nhiều quy trinh.
ờ vụ ci/cd tôi biết nó chạy thế nào mà, cái đó không phải là trọng điểm. trọng điểm ở đây như tôi nói, là rõ ràng *trong trường hợp này* có thể sửa trực tiếp trên nginx file để xem hiệu quả luôn, không lãng phí thời gian của nhau. về sau thấy ổn định rồi/rảnh rỗi thì có thể migrate vào code sau.

tất nhiên tôi cũng biết đây là do bạn dev kia không biết cái này (nhiều người còn không biết http header nó có gì hoạt động thế nào), hoặc không tự tin làm vụ này do bình thường không tự chọc ngoáy nginx các kiểu, cho nên ngày từ bài post đầu tôi đã bày tỏ quan điểm là các bạn nên dùng linux để thêm kinh nghiệm, làm quen với những công cụ tiện ích có sẵn trên server, tương lai biết mà dùng.
 
Đối vs usecase ông Nipin thì ko xài docker thì tiện hơn là điều ko bàn cãi r :3
Cố đấm cái docker ( nhiều khi chạy riêng docker thôi đã ngôn ram, resourrce hơn cái con crawler của ổng r ) làm j
 
ờ vụ ci/cd tôi biết nó chạy thế nào mà, cái đó không phải là trọng điểm. trọng điểm ở đây như tôi nói, là rõ ràng *trong trường hợp này* có thể sửa trực tiếp trên nginx file để xem hiệu quả luôn, không lãng phí thời gian của nhau. về sau thấy ổn định rồi/rảnh rỗi thì có thể migrate vào code sau.

tất nhiên tôi cũng biết đây là do bạn dev kia không biết cái này (nhiều người còn không biết http header nó có gì hoạt động thế nào), hoặc không tự tin làm vụ này do bình thường không tự chọc ngoáy nginx các kiểu, cho nên ngày từ bài post đầu tôi đã bày tỏ quan điểm là các bạn nên dùng linux để thêm kinh nghiệm, làm quen với những công cụ tiện ích có sẵn trên server, tương lai biết mà dùng.

Tại tùy cty thôi, chứ nhiều cty đâu phải dev dc quyết định. Config rồi phải review code. approve nữa.

Gặp mấy cty gắt security. Giải trình ssh vào server production nữa.

Còn ai làm backend lâu năm thì tôi nghĩ họ chỉ chuyển sang mac đc vài năm nay thôi. Chứ ngày xưa chả xài linux nát ra rồi. Làm mấy cty nhỏ thì cứ combo ubuntu, window thôi. :LOL:
Còn về 2pic này thì tôi thấy hiện tại mac cho general dev là good rồi. Ai hardcore thì tùy. Chứ về mặt User exp thì linux chưa thấy có cái distro nào ngon. Tui linux nghĩ ai xài cũng là tech savvy hết.

chưa tính phần mềm nữa.

Mà cái 2pic này ss mac và win mà. Lan man bữa giờ vãi lềnh :eek:
 
Sửa lần cuối:
Tại tùy cty thôi, chứ nhiều cty đâu phải dev dc quyết định. Config rồi phải review code. approve nữa.

Gặp mấy cty gắt security. Giải trình ssh vào server production nữa.

Còn ai làm backend lâu năm thì tôi nghĩ họ chỉ chuyển sang mac đc vài năm nay thôi. Chứ ngày xưa chả xài linux nát ra rồi. Làm mấy cty nhỏ thì cứ combo ubuntu, window thôi. :LOL:
Còn về 2pic này thì tôi thấy hiện tại mac cho general dev là good rồi. Ai hardcore thì tùy. Chứ về mặt User exp thì linux chưa thấy có cái distro nào ngon. Tui linux nghĩ ai xài cũng là tech savy hết.

chưa tính phần mềm nữa.
vụ công ty gắt security thì tôi không có kinh nghiệm, các bạn coi như là nói chuyện phiếm: gần đây có vụ phốt của cloudflare, trong đó có đề cập đến có vài người có privilege cực cao, có thể bypass tất cả security khi cần thiết, thiết nghĩ các công ty khác cũng thế thôi chứ nhỉ?

mà bạn đang nói là làm backend lâu năm rồi, đây cũng là cái tôi nói từ đầu, đã lên pro rồi thì không cần thiết phải cứ đấm ăn xôi dùng linux cho bằng được. nhưng chưa pro thì đừng nên chối đây đẩy, như vài bạn phản biện với tôi có ngụ ý là "giờ docker/k8s có hết tất cả tính năng rồi cần gì phải dùng linux".

mà thôi tôi cũng hết hứng bàn luận tiếp topic này rồi, nói đi nói lại toàn lặp lại mấy ý ban đầu, rất mệt.
 
vụ công ty gắt security thì tôi không có kinh nghiệm, các bạn coi như là nói chuyện phiếm: gần đây có vụ phốt của cloudflare, trong đó có đề cập đến có vài người có privilege cực cao, có thể bypass tất cả security khi cần thiết, thiết nghĩ các công ty khác cũng thế thôi chứ nhỉ?

mà bạn đang nói là làm backend lâu năm rồi, đây cũng là cái tôi nói từ đầu, đã lên pro rồi thì không cần thiết phải cứ đấm ăn xôi dùng linux cho bằng được. nhưng chưa pro thì đừng nên chối đây đẩy, như vài bạn phản biện với tôi có ngụ ý là "giờ docker/k8s có hết tất cả tính năng rồi cần gì phải dùng linux".

mà thôi tôi cũng hết hứng bàn luận tiếp topic này rồi, nói đi nói lại toàn lặp lại mấy ý ban đầu, rất mệt.

Tôi đâu có bênh mấy ông docker nãy giờ cũng đâu có hương ứng docker :big_smile:Tôi chỉ khuyến khích cái nao đúng usecase thì xài. Nên ai xài docker gi đó ko có về nhà nấy.
 
nói chung mindset của ông Nipin là làm hobby project với lại dự án nhỏ không cần scale thì giải thích kiểu gì cũng vậy thôi, mấy cái bài toán ông đưa ra cũng là toàn bài toán lặt vặt không quan tâm tới tối ưu hay không thì dùng kiểu gì chả được, ông ấy chưa gặp những vấn đề mà người khác gặp thì đưa ra cách giải quyết ông ấy cũng chẳng hiểu được
 
nói chung mindset của ông Nipin là làm hobby project với lại dự án nhỏ không cần scale thì giải thích kiểu gì cũng vậy thôi, mấy cái bài toán ông đưa ra cũng là toàn bài toán lặt vặt không quan tâm tới tối ưu hay không thì dùng kiểu gì chả được, ông ấy chưa gặp những vấn đề mà người khác gặp thì đưa ra cách giải quyết ông ấy cũng chẳng hiểu được
thôi thì tuỳ bạn, bạn đúng.
thực ra tôi còn định tranh luận vụ inode full/disk full thì docker/k8s giải quyết kiểu gì, cơ mà do tôi trình độ lùn các bạn có đưa cách giải quyết thì tôi cũng chẳng hiểu được đâu, cho nên thôi :v
 
thôi thì tuỳ bạn, bạn đúng.
thực ra tôi còn định tranh luận vụ inode full/disk full thì docker/k8s giải quyết kiểu gì, cơ mà do tôi trình độ lùn các bạn có đưa cách giải quyết thì tôi cũng chẳng hiểu được đâu, cho nên thôi :v

có cái giả thuyết https://12factor.net này tôi thấy cũng khá hợp lý này, bạn thử đánh giá service bạn build được bao nhiêu điểm nào, tôi build service trên k8s nhẹ nhàng không tốn nhiều effort cũng đạt được 11/12 rồi
 
có cái giả thuyết https://12factor.net này tôi thấy cũng khá hợp lý này, bạn thử đánh giá service bạn build được bao nhiêu điểm nào, tôi build service trên k8s nhẹ nhàng không tốn nhiều effort cũng đạt được 11/12 rồi
ừ bạn đúng. tôi xin phép từ giờ không trả lời bài của bạn. interest quá khác biệt không có gì để nói.
 
ừ bạn đúng. tôi xin phép từ giờ không trả lời bài của bạn. interest quá khác biệt không có gì để nói.

chết cười, thay vì tìm hiểu thêm để bổ sung kiến thức cải thiện hiệu quả làm việc thì lại ... :LOL::LOL::LOL::LOL:
 
chết cười, thay vì tìm hiểu thêm để bổ sung kiến thức cải thiện hiệu quả làm việc thì lại ... :LOL::LOL::LOL::LOL:
vấn đề là cái 12 factor của bạn nổi tiếng tới đâu? ai cũng nhắc tới như là tiêu chuẩn bắt buộc phải theo hay chỉ có vài người nói? nếu chỉ có vài người nói thì nó có ý nghĩa gì? ngày xưa tôi cũng nghĩ làm phần mềm là phải thế này thế kia, càng làm mới biết là có nhiều thứ chỉ là lý tưởng hoá, ai cũng biết có được thì rất tốt, nhưng thực tế ứng dụng thì nó còn rất nhiều thứ khác phải cân nhắc.

mà tôi hỏi thật bạn đã có kinh nghiệm làm các dự nào rồi, dự án nào cũng docker/k8s cả? dự án nào cũng ci/cd hết? (tôi rất thắc mằc cái này bởi vì ci/cd docker/k8s cũng mới đây thôi, không phải là ngay từ đầu đã là industry standard, rất tò mò là trước khi có mấy cái đó thì bạn làm cái gì)
 
k8s thì tôi làm tầm hơn 2 năm trở lại đây thôi còn ci/cd thì lâu rồi, ngày xưa lại còn chẳng viết script cho jenkins để automate hay sao, dự án thì lớn cũng gọi là hơn mức nhỏ xíu nhưng lớn hơn mức có thể deploy, troubleshoot bằng tay như bạn, tổng user cũng tầm 1m người thôi
 
k8s thì tôi làm tầm hơn 2 năm trở lại đây thôi còn ci/cd thì lâu rồi, ngày xưa lại còn chẳng viết script cho jenkins để automate hay sao, dự án thì lớn cũng gọi là hơn mức nhỏ xíu nhưng lớn hơn mức có thể deploy, troubleshoot bằng tay như bạn, tổng user cũng tầm 1m người thôi
cái tôi quan tâm là bạn làm dự án nhiều năm như thế, gặp những usecase nào lạ rồi, lúc đó bạn giải quyết thế nào, về sau khi đổi sang ci/cd hay docker thì nó được giải quyết effortless ra làm sao, như thế mới thuyết phục.

p/s: kiểu như cái 12 factor kia, nghe thì rất hay, nhưng bạn phải nói ra là factor này đã giúp tôi giải quyết dc trường hợp cụ thể này cụ thể kia, nếu không thì khác gì không có việc tìm việc?
 
bonus một cái xkcd khá relevant:
https://xkcd.com/1205/
is_it_worth_the_time.png

p/s: cái này nữa:
automation.png


tôi không phủ nhận là automation thì rất tiện, nhưng nhiều lúc manual cũng có lý do của nó.
 
cái tôi quan tâm là bạn làm dự án nhiều năm như thế, gặp những usecase nào lạ rồi, lúc đó bạn giải quyết thế nào, về sau khi đổi sang ci/cd hay docker thì nó được giải quyết effortless ra làm sao, như thế mới thuyết phục.

đổi sang k8s thì setup CI/CD dễ hơn nhiều so với deploy trên VM, quản lý resource cho từng workload dễ hơn, autoscale được, những thứ như logging, tracing, apm, ... setup cũng nhanh hơn
 
đổi sang k8s thì setup CI/CD dễ hơn nhiều so với deploy trên VM, quản lý resource cho từng workload dễ hơn, autoscale được, những thứ như logging, tracing, apm, ... setup cũng nhanh hơn
bạn nói như vẹt... ừ không phải tôi muốn chê bạn, nhưng những lý do này tôi đọc cái landing page của k8s nó cũng có.

tôi nói cụ thể bài toán cơ mà, ví dụ như sau khi sang k8s thì bạn tiết kiệm được bao nhiêu thời gian, trước đó không có thì phải làm thế nào, error prone các kiểu thế nào. quản lý resource dễ hơn ra sao, handle spikes thế nào (kiểu như ngày nào giờ nào web của bọn tôi đột nhiên nổi tiếng có lượng user tăng đột biến thì làm ra sao các kiểu)....

cái tôi quan tâm là real benefit, real world usage, không phải là lý thuyết.
 
bạn nói như vẹt... ừ không phải tôi muốn chê bạn, nhưng những lý do này tôi đọc cái landing page của k8s nó cũng có.

tôi nói cụ thể bài toán cơ mà, ví dụ như sau khi sang k8s thì bạn tiết kiệm được bao nhiêu thời gian, trước đó không có thì phải làm thế nào, error prone các kiểu thế nào. quản lý resource dễ hơn ra sao, handle spikes thế nào (kiểu như ngày nào giờ nào web của bọn tôi đột nhiên nổi tiếng có lượng user tăng đột biến thì làm ra sao các kiểu)....

cái tôi quan tâm là real benefit, real world usage, không phải là lý thuyết.

tôi lấy một ví dụ nhé, vd như việc vận hành một cluster kafka đi, ngày xưa tôi setup bằng tay, phải tự sửa file config cho zookeeper, kafka bằng tay, muốn thêm topic hoặc partition thì phải dùng command gõ này nọ, đặc biệt muốn giảm bớt node hoặc partition là một cực hình, còn nếu như trên k8s tôi dùng strimzi operator để deploy kafka, kết hợp với ci/cd có sẵn thì tôi muốn config bao nhiêu topic, bao nhiêu partition, tăng giảm node thì chỉ cần sửa file mô tả resource, commit git rồi ngồi uống cafe đợi nó làm hết cho tôi
 
tôi lấy một ví dụ nhé, vd như việc vận hành một cluster kafka đi, ngày xưa tôi setup bằng tay, phải tự sửa file config cho zookeeper, kafka bằng tay, muốn thêm topic hoặc partition thì phải dùng command gõ này nọ, đặc biệt muốn giảm bớt node hoặc partition là một cực hình, còn nếu như trên k8s tôi dùng strimzi operator để deploy kafka, kết hợp với ci/cd có sẵn thì tôi muốn config bao nhiêu topic, bao nhiêu partition, tăng giảm node thì chỉ cần sửa file mô tả resource, commit git rồi ngồi uống cafe đợi nó làm hết cho tôi
ờ đây là một usecase, cơ mà tôi không dùng kafka cho nên không hiểu, cũng không thấy hứng thú, bạn có thể đưa thêm cái ví dụ nào generic hơn được không? cái mà mọi người đều áp dụng được?

p/s: bởi vì tôi đọc thấy thì chủ yếu là do kafka bản chất là enterprise software config lằng nhằng, nhưng mà thiên hạ còn rất nhiều người không dùng enterprise software bạn ạ.
nếu tất cả các ví dụ của bạn đều dính dáng đến enterprise software thì không nói cũng được, như tôi nói từ trước, hiển nhiên là hứng thú mỗi người khác nhau, không có gì để nói.
 
ờ đây là một usecase, cơ mà tôi không dùng kafka cho nên không hiểu, cũng không thấy hứng thú, bạn có thể đưa thêm cái ví dụ nào generic hơn được không? cái mà mọi người đều áp dụng được?

thế bạn liệt kê những gì bạn dùng đi rồi tôi xem cái gì trùng với tôi mới kể được mấy cái hay ho chứ, tôi ví dụ kafka là vì nó cũng khá phổ biến rồi đấy
 

Thống kê chủ đề

Ngày tạo
bamboo.bamboo,
Người trả lời cuối
2TbP,
Trả lời
597
Lượt xem
77.819
Quay lại
Lên đầu trang