The vaccine situation in Veneto is complex. It's not "first come, first served". There are different cohorts. Right now the only people that are eligible are people over 80 and people with pre-existing health conditions.
Many of them have troubles using the official portal, and they ask their children to help them. Their children are around 50, and have to actively poll the website trying to get a spot.
I didn't build the bot for young, tech savvy people who want to get first in the line. It's exactly the opposite. By smoothing the UX it makes booking the spot for the vaccine accessible, and it removes the burden of constantly check it. It may also help in avoiding wasting doses by sending last minute notifications about new available spots.
I have few emails from people thanking me because they were frustrated by the official website, and the bot helped them to book a spot for their parents.
I'm not a lawyer but "codice fiscale" is not PHI. The Italian Data Protection Authority puts codice fiscale under PII[0] and it's not mentioned in the PHI section[1,2,3,4].
The thing that backend devs don't realize is that frontend is not easy. A frontend dev builds something that will be used by a HUMAN, while a backend dev builds something that will be used by a PROGRAM. Related to the comment, things were changing a lot because there is not one single way to do things, as in iOS/Android. There is no standard imposed by a huge private company like Apple or Google. Everyone is free to reinvent the wheel.
Facebook did something super valuable, that is ReactJS, and this is becoming the _de facto standard_. ReactJS is simple, opinionated, and supported by a large corporation. Thanks to ReactJS a new ecosystem was born, and now finally you have many projects gravitating around it, and this is good. It's just a matter of time IMO.
I strongly disagree with _"the browser is a bad app platform and javascript is a bad language"_. JavaScript has its quirks, but it's also really plesant to work with if you don't do weird shit like `isNaN('wft' - 1) // it's true`. The browser is a great virtual machine that is democratizing the web. If you are doing things right, you can have graceful degradation (it degrade gracefully to a lower level of user in experience in older browsers) to increase the audience of your web app, from the dev in SF with gigabit internet to someone living in a rural area in a not so tech advanced country. This of course has a cost, that is spending time developing your app.
I'm the main developer of the extension. We use the public post to connect your Facebook profile with your user in our database. If you want you can just publish the public key without anything else. After we validate your key, you can remove the post.
If you have any suggestion on how to improve feel free to open an issue:
The thing is that at the beginning we were just three friends trying to develop a simple webapp. The domain hack (.st) was to keep our URLs short. The .com domain was parked. As you wrote, "I was happy with that situation". Well, I was not happy but I though it was not so important.
Now we are a company and things are different.
My fault was to not act directly against it. The urlist.com guy did a fake landing page with our contents before, now he is linking to a webapp related to bookmarking: he know what he is doing.
I was wondering if anyone has ever experienced a problem like this one, and what he/she have done to solve it :)
Dear HN,
since I'm a little bit disappointed with the newtwitter newlayout, i made a tiny greasemonkey script to fix it, and I'm sharing it with you.
The script puts the timeline on the left and fixes also the ">" icons con the menu sidebar (using "transform: rotate(180deg)") for your viewing pleasure.
1. install greasemonkey (skip this step if you are using Chrome)
I don't want to seem inquisitive, but it looks a lot like VIM. I thought it was VIM, or a human-friendly version of it.
I took a look to http://www.sublimetext.com/features and many of the features listed are available on a vanilla VIM. Many, if not all, except "Asynchronous file loading, so you're never blocked when loading files off slow network drives", "WinSCP integration for editing remote files via SCP and FTP" (OK, maybe you can have the last one using sshfs).
[edited, I've removed "Commenting and uncommenting blocks of text" from the features vim does not have.]
In my experience, even if you are building a quick'n'dirty prototype, you'll always need to fire up a terminal or run the GUI to interact/play with the prototype you are building, to see if it "works".
In this case you may apply a --this is my very own definition-- "lightweight TDD approach" just to automate all the procedures that you normally do to test your prototype. Moreover, since you are writing a test for something that does not exist, it may help you defining better what you want from your experimental code, because you are using your prototype before it even exists :)
I strongly agree with all the 5 rules Randall pointed out. But, IMHO, the very first step to really understand those rules is to dramatically fail on every one.
[this is my first comment on HN! :)]