Open source survey application

Due to business requirements, I have forked and re-skinned a legacy PHP survey application with material design.

To give back to the community, here’s the updated source:

https://github.com/thanhphu/php-survey-builder

It contains the following improvements

  • Add material design for user-facing pages
  • Add appropriate ignore to avoid leaking credentials on source control
  • Add default user ID you can set via GET parameter when sending out mass email
  • Stricter .htaccess
  • More readable fonts

Troubleshoot running JMeter programmatically

Resolving “Could not find org.apache.jmeter:bom”

With the release of the v5 of the JMeter library comes a bug. When you include JMeter gradle will complain that it “Could not find org.apache.jmeter:bom”. To resolve this, edit build.gradle to say

// There's a bug in JMeter leaving extra metadata right now. This is a workaround
class JMeterRule implements ComponentMetadataRule {
    void execute(ComponentMetadataContext context) {
        context.details.allVariants {
            withDependencies {
                removeAll { it.group == "org.apache.jmeter" && it.name == "bom" }
            }
        }
    }
}

dependencies {
    implementation group: 'org.apache.jmeter', name: 'ApacheJMeter_core', version: '5.3'
    implementation group: 'org.apache.jmeter', name: 'jorphan', version: '5.3'

    components {
        withModule("org.apache.jmeter:ApacheJMeter_core", JMeterRule)
        withModule("org.apache.jmeter:ApacheJMeter_java", JMeterRule)
        withModule("org.apache.jmeter:ApacheJMeter", JMeterRule)
        withModule("org.apache.jmeter:jorphan", JMeterRule)
    }
}

Chính trị trong phát triển phần mềm

Các kỹ sư phần mềm có thể được xem như các anh nông dân 4.0: hiền lành, chất phác, không sỡ hữu công cụ sản xuất, chỉ muốn được yên thân ngồi một góc để làm việc.

Oái oăm thay, cây muốn lặng mà gió chẳng dừng. Có rất nhiều vấn đề một kỹ sư phần mềm phải giải quyết ngoài chuyên môn công việc, trong đó bao gồm chính trị trong phát triển phần mềm.

Làm phần mềm cũng có chính trị?

“Chính trị” ngoài nghĩa hẹp là các tranh đấu có tính vĩ mô về điều hành một đất nước còn có nghĩa rộng là tương tác giữa một nhóm người với nhau. Trong phần mềm có rất nhiều bộ phận tham gia: marketing, product owner, project managers, designer, developer… nên hiển nhiên 9 người 10 ý, ai cũng muốn ý kiến của mình được tiếp thu và thực hiện, dẫn đến tranh đấu.

Chính trị len lỏi vào mọi ngách trong cuộc sống!

Một số loại chính trị có thể gặp trong phát triển phần mềm

Trong việc lựa chọn tính năng của phần mềm và lập kế hoạch

Đây là loại chính trị diễn ra thường xuyên nhất và căn bản nhất. Khi làm phần mềm hiển nhiên không thể làm một lúc hết các tính năng mà phải chia ra thành milestones và phân phối các tính năng một cách hợp lý.

Tuy nhiên thế nào là “hợp lý” thì còn tuỳ vào quan điểm của từng bộ phận tham gia khác nhau!

Người kỹ sư thường xem xét vấn đề theo quan điểm kỹ thuật, rằng tính năng A làm trước thì làm tính năng B sẽ dễ hơn. Nhưng marketing thì lại thấy nếu cho ra tính năng B ngay thì có thể chạy campaign viral do một sự kiện gần đây… Kết quả là việc có thể chỉ cần 1 ngày để làm nhưng bàn luận nên làm trước hay sau thì lại cần đến một tuần!

Nếu người kỹ sư là người có bản tính ngại tranh đấu sẽ chịu rất nhiều thiệt thòi khi tranh luận. Do đó để tồn tại trong nghề phát triển phần mềm người kỹ sư cần rèn luyện kỹ năng phát biểu, tranh luận và trang bị một tính cách vững vàng cho bản thân.

Trong việc đánh giá công việc

Những người có vai trò lãnh đạo với tấm bằng MBA rất thích quantification và measure performance. Tuy nhiên trong phát triển phần mềm thì khó có một cách đo đếm performance một cách khách quan và phản ánh đúng thực tiễn. Tuy nhiên điều này vẫn không ngăn lãnh đạo muốn áp dụng thử.

Và kết quả là performance review.

Performance review rất tốn công sức của kỹ sư, vì đó không phải là việc của họ. Họ cần có kỹ năng chuẩn bị một bài ca con cá tự ca ngợi các thành quả mình đã làm, họ cần phải chứng tỏ mình là một kỹ sư xuất chúng bằng cách tranh giành làm những project có impact lớn, làm những project không bao gồm trong phân công…

Một số công ty còn bắt buộc nhân viên “trèo lên đầu nhau mà sống” bằng stack ranking (xếp hạng review từ cao đến thấp, cao thì được thưởng, thấp thì bị trừng phạt, cho dù có làm tốt đi chăng nữa nhưng không tốt bằng người khác hoặc team khác vẫn bị phạt!) và bắt buộc phải chỉ ra điểm cần cải thiện của đồng nghiệp khi làm performance review.

Do đó khi phỏng vấn nên hỏi kỹ một năm công ty tổ chức đánh giá mấy lần? Một lần là đủ, hai lần là hơi nhiều, ba lần trở lên — bạn nên tìm công ty khác để làm phần mềm vì ở công ty này bạn sẽ trở thành nhân vật trong Game of thrones.

Hoạt động đối ngoại

Việc kỹ sư phần mềm phải đối ngoại không phải là việc diễn ra hằng ngày, tuy nhiên vẫn diễn ra khá thường xuyên: kỹ sư phần mềm phải làm việc với người ở công ty đối tác, đến công ty đối tác để cài đặt hoặc thảo luận… Đối với người làm phần mềm nguồn mở (và pseudo-open source) thì còn phải nhận báo cáo lỗi từ bên ngoài và trả lời sao cho hợp tình hợp lý.

Một ví dụ rất không đẹp từ bluez**e: khi nhận góp ý từ chuyên gia thì các anh kỹ sư thiếu não không thèm phản biện mà tạo nick clone vào tấn công cá nhân chuyên gia.

Nếu đây là một công ty làm ăn đàng hoàng thì các anh ấy đã mất việc, tuy nhiên, đây là công ty B, một công ty rất giỏi marketing bằng scandal.

Khi bạn trả lời khách hàng hoặc đối tác, bạn là đại diện của công ty. Hành động của bạn sẽ được cân đong đo đếm và dùng để đánh giá công ty của bạn. Cần cân nhắc và hành động sao cho hợp lý, hình ảnh bản thân của bạn cũng sẽ được nâng cao!

Hoạt động đối nội

Cuối cùng và quan trọng nhất, trong nội bộ công ty rất dễ sinh ra bè phái hoặc người có quyền sẽ thích một số người này và không thích một số người kia. Việc này là rất bình thường trong xã hội nhưng khi nó xảy ra ở công ty, nó sẽ ảnh hưởng trực tiếp đến anh kỹ sư phần mềm. Loại chính trị này không chỉ có ở công ty phần mềm mà có mặt ở hầu hết mọi loại doanh nghiệp.

Khi công ty xảy ra khó khăn, ai sẽ là người lên thớt đầu tiên?

Không phải anh kỹ sư không làm được việc, mà là anh kỹ sư không thân với sếp, cho dù anh ấy có giỏi hơn đi nữa! Trên quan điểm của người quản lý, tìm một người làm đúng ý mình thì khó hơn là tìm một người giỏi chuyên môn.

Do đó, người kỹ sư phần mềm cần khéo léo trong việc giải quyết bất hoà trong công ty, không gây mâu thuẫn nội bộ, làm thân với các thành phần cần thiết phải làm thân (mà cách đơn giản nhất là hút thuốc cùng hay đi nhậu chung).

Làm thế nào để đánh giá chính trị trong một công ty tốt hay không

Nói chung một công ty càng ít các vấn đề về chính trị, luôn luôn thông báo rõ đường lối phát triển cho mọi cá nhân trong công ty là một công ty tốt. Để biết một công ty có tốt không thì cách nhanh nhất là đọc review trên các website như blind (nếu là công ty cùng ngành) hoặc glassdoor.

Công ty F

Công ty F là một công ty phần mềm ở nước V, chuyên môn làm các dự án outsource cho thị trường các nước phát triển. Công ty F luôn luôn nhấn mạnh về các chương trình đào tạo nội bộ khi tuyển dụng ứng viên: đào tạo ngoại ngữ để phục vụ nhu cầu ở nước khách hàng, nước J.

Một nhân viên công ty F muốn phát triển bản thân đã đăng ký học khoá học tiếng J. Tuy nhiên trước khi khoá học bắt đầu anh này được tin mình có học bổng đi Mỹ, thế là anh xin nghỉ.

Công ty F đã bắt anh phải hoàn lại tiền của khoá học tiếng J, một số tiền khá lớn với anh, cho dù anh chưa học được một ngày nào.

Đây là một động thái chính trị chèn ép nhân viên dựa vào nguyên tắc tự bịa ra. Khi tranh cãi này được công bố lên các phương tiện thông tin đại chúng thì công ty F đã rút yêu cầu và đắm xuồng vụ việc.

Bài học: hãy quen vài người bạn làm nhà báo.

Công ty A

A là một công ty về thương mại điện tử. A rất khéo léo khi chơi các con bài chính trị. A đã nhử miếng mồi là sẽ xây cơ sở 2 ở “đâu đấy” và chờ các thành phố lên tiếng ưu đãi đủ thứ cho A.

Trong khi thật ra A đã dư biết sẽ xây cái gì ở đâu.

Khi tình hình lợi nhuận sụt giảm, A vẫn tuyên truyền rằng mình đang tuyển dụng rất nhiều người để nhận ưu đãi thuế của chính phủ…

… tuy nhiên trong nội bộ A thì A dùng cớ performance review để loại bớt nhân viên.

https://www.teamblind.com/post/amazon-laying-off-en-masse-2020-QqdXSZzr

Công ty C

Công ty C cũng giống như A, là công ty về thương mại điện tử. Công ty C lại hoạt động ở thị trường Hàn Quốc. Một năm C bắt nhân viên performance review… 4 lần. Cũng giống như A, khi tình hình kinh tế khó khăn không ty C lại giở trò performance review và nợ lương nhân viên.

How to fork a go library (my way)

  • Git fork
  • Go mod init if not yet a module
  • Update path to new module github.com/someone/library -> github.com/you/library. This is because the module will continue to look for dependencies in the old path
  • Bump version with a tag (v1.0.0 -> v1.0.1)
  • Push the tag to Git
  • Go mod tidy in any project using the go library

Prune big files from Git with BFG

Step 2: Clone your repo as a mirror

Run this to clone your repo as a mirror.

git clone --mirror git://example.com/your-repo.git

The —-mirror flag means that it doesn’t actually download any of the files from your codebase. It downloads the .git directory contents into the top level, so it looks a little funky at first.

Step 3: Back up your repo

Just in case, now is a good idea to back up your repo to a separate location so that you can restore from it if needed.

cp -r your-repo.git your-repo-backup.git

Step 4: Run BFG to remove large blobs

In BFG, you have 3 main options for clearing out large files from your Git history.

Note: “blobs” are the objects that store file contents in Git.

Option 1: Strip blobs bigger than a specified size

In this case, you’re telling BFG to remove any blobs from history that are larger than a specified size. For example, to strip out any blobs bigger than 10MB, you run:

bfg --strip-blobs-bigger-than 10M your-repo.git

Option 2: Strip the biggest blobs, limited to a specified number

If you’d rather just strip the biggest blobs regardless of how large they are, BFG makes that easy:

bfg --strip-biggest-blobs 100 your-repo.git

This command will strip the 100 largest blobs from your repo history.

Option 3: Strip specific blobs, specified by IDs

If you know of specific files you want to get rid of, you can take this approach. In this case, you’ll pass in a text file that contains the list of blob IDs you want to strip.

bfg --strip-blobs-with-ids blobs.txt your-repo.git

You can use a one-liner like this like this to find the IDs of the largest blobs.

Protecting specific branches

BFG is very good at making sure that it doesn’t touch any of the files on your HEAD. It only adjusts your history, not the files in your latest commit.

But if you have other branches you want to make sure you protect, you can do that with the --protect-blobs-from flag:

bfg --protect-blobs-from master,dev,stage --strip-biggest-blobs 100 your-repo.git

Step 5: Expire and prune your repo

You’re removing things with BFG. Now it’s time to expire and prune your git history to reflect your changes. Here’s how you’d do that:

cd your-repo.git git reflog expire --expire=now --all && git gc --prune=now --aggressive

Note that this command can take a long time depending on your repo size. So it’s best to make sure you’re done running BFG first. You only want to have to run this command one time.

Step 6: Check your repo size

Verification time! Did the repo shrink? If not, then you probably missed a step or didn’t remove the correct files.

Step 7: Push your changes

Now you’re ready to push all your updates so that everyone can enjoy the new, slimmer repo you have fashioned.

git push

And that’s that! Your repo should be smaller, without any noticeable negative effects. Thanks BFG!

source: https://www.phase2technology.com/blog/removing-large-files-git-bfg