TBurette

I worked for a company that required security clearances. We used a SaaS to store some documents. The SaaS gave our company a document outlining their security practices and we signed up to a system where their support is unable to access our instance unless we explicitly authorized it. It was enough for our company.

What I find remarkable is that multiple people can say 'I am a Wordpress Developer' and it will translate into very different experiences and skillsets.

For some it means clicking around installing theme, plugins then writing the content of pages through the Wordpress admin.

For others it means old school php code to customize Wordpress behaviour with PHP template to write the HTML. This is called classic theme.

For yet other people it means writing JS+React with docker, CI/CD,... This is the new block theme.

The goal is to prevent any way for attackers to inject code.

Bookmarklets and user scripts are collateral damage.

Is there a good way to combine Scrapy framework (retry, rate limiting,..) with a headless browser such as selenium (to get full js-loaded client-side data)?

When I had to do it I ended up duplicating each page request twice. Once for scrapy and once again with selenium.

I remember that the introduction of the new WebExtension API to replace the existing extension system was heavily criticized. The old system gave extensions deep access to the browser and the new extension API (copied over from the Chrome browser) was seen as a limiting dumbing down.

It was a painful transition but very much needed. Now extensions don't clash with one another. The browser code can be modified more freely without impacting extensions and it is possible to implement features such as sandboxing.

Writing a class that represents a property on an object so that you can reuse the property as many time as needed is nice.

What is less nice is that the implementation of that idea in python is so tricky. Descriptors come in two flavours and behave differently depending on their type : data descriptor and non data descriptor. Doing something simple as having a descriptor writing a value in an object without clashing with other descriptors/objects is tricky. Thank god they added __set_name__ in 3.6.

I have a laptop with hidpi (14" 2560x1440) and I gave up : I now use a non-native lower resolution.

I tried x11, I tried wayland, I tried scaling, I tried fractional scaling, I tried changing default font size. I always ended up with text too small, text too blurry or inconsistencies between applications.

Right from the start the idea was not to have just a forum with questions and answers but a curated repository of knowledge. There would therefore be an active moderation. Duplicated questions would be closed, out of topic ones would be deleted, questions/answers could be edited,...

This ended up in a culture of active and sometimes heavy-handed moderation that 's now part of the DNA of the site.

The CAP theorem applies whenever you have a distributed data store. This means a system you can write data to and read back from. This system is made of multiple nodes connected through a network and the clients can connect and make read/write requests from any node.

If you don't meet those conditions CAP doesn't apply to you. For example :

- an SQL database with master/slave replication but all the clients only ever access the database from the same nod (the clients will always have a consistent view of the one node they access)

- multiple processes on the same machine doesn't apply (it's a concurrent datastore but not a distributed one)

- a single SQL database instance doesn't apply (data is not distributed even if there are multiple clients. Confusingly enough if clients can keep some data and work in offline mode, then it would apply because the clients would be considered as a node of the system)

CAP was clearly created in the context of distributed database : SQL, noSQL, CDN,... Can it apply to an entire system made of multiple components such as database, multiple services,... ? Things get muddier but I'd say yes as long as you check all the boxes: a system with data spread on multiple nodes that clients can access to where the connection can get severed.

Application servers with no local copy losing connection to the server : no. Where is the distribution of data? Where can a network failure partition the data? There is not much A or C choice to make when a partition occurs. Applying CAP wouldn't be very interesting here.

However application servers with local copy : yes CAP applies. In case of a partition there is a trade-off to be made between C and A.

To complicate things further, CAP has basically two versions. There is Brewer's version which talks in general terms is not formal and gets hazy when you drill down to the details. The other version is the one of Lynchs's Paper that provided a proof for the CAP theorem. In that version the definitions are very strict and consequently many real worlds aspects don't fit. Depending on who you ask you may get different answers.

For example, take the context of a database distributed on multiple servers in a datacenter with a reverse proxy that can detect partitions and always redirect read/write queries to non-partitioned nodes. In that context you could say that you have all three C, A and P because there is never going to be a request on a partitioned node. According to Lynch's version of CAP this is not C consistent because you have non-failing nodes that can read stale data (the question of whether there is going to be any request or not is outside the purview of the proof).

To me, copy/paste is a weakness of a workflow using tmux.

With tmux you end up with four distinct copy/paste buffers: the OS, tmux, the shell, vi/emacs. You do get used to the mental gymnastic of juggling all those but it's not ideal.

Same goes with managing the windows of the OS, tmux and vi/emacs.

Make it check for errors by default instead of blindly keeping running (set -euo by default).

Have a way to undelete files (undelete or a trash folder).

Not being so whitespace sensitive. One of those two commands does what you think it does, the other not : grep --exclude-dir= ".git" -rl 123 . grep --exclude-dir=".git" -rl 123 .

Make it easier to iterate through file of a directory no matter what the filenames may contain(dashes, spaces,...)

Be more consistant between different commands.

  adduser vs newgrp
  -o vs + (Or-ing elements)

Use a modern regexp. For example with grep x* works but x? doesn't (you must use x\? or a flag)

Write man pages so that they are useful in the 'I have an idea what this command does and want to learn it' scenario, not just 'I know this command and need a quick refresher on a specific flag'.

Continuous integration is when the developers merge their code into a shared master branch at least once a day, ideally several times a day.

A mandatory code review before merging is allowed (that takes some time to be processed) leads to fewer, bigger merges. Imagine waiting for reviews of the 10 pull requests of wrote two days ago, the 10 of yesterday and 5 you created so far today. It's too unwieldy. The latency encourages you to start writing fewer bigger pull requests more spaced out in time.

As an aside, it also tends to reduce trust and cooperation within a team : reviewers become the gatekeepers of the work of contributors. That work is explicitly not trusted until it is checked. Not a great social dynamic I think.

You didn't just change the source control tool you also fundamentally changed the development process. You used to do continuous integration. Now you are doing feature branching instead.

Feature branching is nice in some cases. For example in open-source project this allows a maintainer to review code (of a potentially unknown developer) before it is accepted. It also prevents a contributor to vanish leaving half-finished features.

I believe feature branching is inferior to continuous integration for most private software development teams. Feature branching along with systematic code review add a lot of friction to the integration of a developer's code into the mainline. The consequence is that developers push less commits that become bigger and integrating each developer's code together become a painful process. This starts a negative feedback loop.

If I were you I would look for the evidences that continuous integration make a team perform better and push to keep git but change the workflow back.