TBurette's comments

TBurette | 1 year ago | on: Ask HN: How to handle sensitive document uploads as a one-person SaaS?

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.

TBurette | 1 year ago | on: WP21

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.

TBurette | 3 years ago | on: Web Scraping with Python

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.

TBurette | 4 years ago | on: An enhancement request I submitted to Bugzilla 15 years ago was just closed

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.

TBurette | 4 years ago | on: The Power of Python Descriptors

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.

TBurette | 4 years ago | on: Ask HN: Functioning hidpi setup on Linux, how?

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.

TBurette | 4 years ago | on: Ask HN: In your opinion, what sucks about StackOverflow

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.

TBurette | 4 years ago | on: You Can’t Sacrifice Partition Tolerance (2010)

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).

TBurette | 5 years ago | on: Tmux lets you select and copy text with your keyboard

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.

TBurette | 5 years ago | on: Ask HN: If you could reinvent the Shell, what would you do differently?

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'.

TBurette | 5 years ago | on: Git Sucks, What Am I Doing Wrong?

> Why does continuous integration contradict feature branching?

With feature branching, you wait as long needed before the feature is finished. You can only merge when it is fully finished. This goes directly against the continuous integration philosophy of committing early and often.

> How do you have stable versions of the software if you have unfinished features and hacking in the master version?

It requires a strong commitment to ensure that the current state of the code remains healthy (strong unit tests,...). New in-progress features can remain disabled through feature flags, not showing the corresponding UI or not calling the code.

> I guess this makes sense for very small teams early in the development process but then you can just skip feature branching in git for a while.

It's definitely not for every team.

Martin Fowler presents in detail the 'made up things I just wrote' in this article : https://martinfowler.com/articles/branching-patterns.html . See in particular the Continuous Integration section and the following sections.

TBurette | 5 years ago | on: Git Sucks, What Am I Doing Wrong?

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.

TBurette | 5 years ago | on: Git Sucks, What Am I Doing Wrong?

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.

TBurette | 5 years ago | on: It’s easier to manage four people than one person

C. Northcote Parkinson wrote about single reports in his 1995 Parkinson's law article published by The Economist[1]. That's the article that articulated in its first sentence the Parkinson's law we all know.

In the article he explains that a worker that feels overworked prefers to have subordinates rather than a peer of his own level that would be a rival for promotion.

A single subordinate is not ideal because the work would be divided between the two and the subordinate would assume an almost equal status in practice. With two subordinates each is kept in order by fear of the other's promotion and the new manager has the merit of being the only one to comprehend the work of the subordinates. This sets the stage for the two subordinates getting their own assistants. He explain how this new group of people make work for each other.

[1] http://www.berglas.org/Articles/parkinsons_law.pdf

TBurette | 5 years ago | on: Le fardier de Cugnot: Replica of the first automobile

The original is in the "Musée des arts et métiers" Museum in Paris. I highly recommend to visit the museum if you ever are in Paris. It's filled with all kind of original scientific and engineering devices. Lavoisier device that split water into hydrogen and oxygen. Jaquard's weaving loom using punching cards. Clément Ader's late 19th century attempt at creating a plane. Blaise Pascal's Mechanical calculator. Prototype metre bar. Old supercomputers...

TBurette | 5 years ago | on: A lot of “idiotic” things have reasonable explanations (2011)

It seems people are commenting on the title of the article and not on what the article says : it's easy to think someone is stupid when you read about them making a bad decision in the news.

Classic examples are:

"Hitler was stupid to invade Russia". In fact he needed to conquer oil fields to keep the ability to wage war andhe Russian army was particularly weak at that point.

"Kodak was stupid not to sell digital camera". In fact Kodak did develop digital camera technology. They were behind one of the first commercial digital camera (The Apple QuickTake), they licensed their patent and were number one sellers of digital camera in the US at some point.

It's easy to fall into this trap when you only high level information. I think that when you get more detailed information this effect dissipates. You then realize that there are many factors and stakeholders.

TBurette | 6 years ago | on: Emacs on the iPhone (2014) [video]

Around the same time I wrote a package for Emacs that would run a webserver within emacs so that you could interact with it remotely from a mobile browser: http://thomasburette.com/take-off/ . Since every action you can perform in emacs is just a piece of elisp code you can easily send any command to emacs. The input method on mobile however is another story.

Pretty useless in practice but it was interesting to delve into the emacs source from the elisp code down to the c text rendering part.

TBurette | 6 years ago | on: Bunk bed is $1,200 a month, privacy not included

It is a hostel but they use a fancy startup/VC vibe to sound cool.

You can make a reservation online for a single night for $40-$50. So yes it is a hostel. Same caveats as every hostel apply : reduced privacy, snoring, you can end up with indelicate people and you have to watch out for theft.

I went to a hostel that opened recently in France that looked very similar (no TV in the beds but a curtain you can close). In fact they also called the beds 'pods'. The difference is that it only cost 18€ a night.

TBurette | 6 years ago | on: Privileged Poor vs. Doubly Disadvantaged at Elite Schools

I've been friends with people who had to mind the way they flushed the toilet at home to save money as well as people whose parents' home front lawn I mistook for some farmland.

There are several unspoken differences in the way the two population perceive education and defining your future:

If you fail that's it you're done, you'll have to find some low wage job.

  vs
If this doesn't work out you could always try something else

University is there to get a diploma to get a job to set you in life

  vs
Entering higher education is one more step to further orient you towards your future.

You approach some subjects for the first time. It is real work.

  vs
Higher education is not too hard. You had a good school that prepared you well. You have the time to go out and have fun

You make friends

  vs
You make friend and network

School and your own curiosity will not prevent gaps. Other students seem to all possess 'cultural' references you don't. You sometime have to write down words you don't know to look them up later.

  vs
Your parents brought you to museums/theater/... shared their appreciation of art, history, science,... Things that can come up among educated people / in university

At school If you hand an assignment late you'll get zero. No one will give you up extra time later in life young man.

  vs
You can see someone that's there to help you, you can get an extension on this assignment.

Finding an internship / someone in some industry to help on a project will be a time consuming task with many people no deigning to reply

  vs
Dad is a business owner that asks for a spot for his kid to his accounting firm.
page 1