St-Clock

I think it's pretty hard to get a Python package into the top 360 list while not picking up any maintainers who could climb that learning curve pretty quickly.

I can speak for experience. Py4J is on that list and getting maintainers is very difficult (for various reasons). Packaging is also not something that naturally attracts contributions.

Thank you so much for this shortcut, I was trying a way to find all of the bad known_host entries and this did the trick!

Winter tire (if you have them) and heating are the likely culprits!

We had similar experience! We tried CodeGuru Reviewer on one of our Python codebases (around 71 KLOC) and abandoned it after a week.

The feedback was indeed similar to what standard linters and static analyzers can provide with more noise. I have no doubt they can improve their recommendations as they get more feedback and analyze more codebases, but we were not interested to pay to contribute.

We have had much more success with https://deepsource.io/ , which found real bugs and we generally agree with their recommendations. We are currently evaluating whether or not we will include this service as part of our process.

Deepsource is rule-based, but my understanding is that they are starting to use ML to rank recommendations.

One strategy we are currently implementing is using a second Postgres database synchronized with logical replication.

1. We insert the logs in the main database and periodically delete old logs. We can thus create the log in the same transaction as a record is created/updated/deleted. Yay atomicity!

2. The second database uses logical replication to receive new logs, but it only replicates INSERT operations so old logs are never deleted.

3. The application can show recent logs quickly (who updated the customer profile this week?) and if the user wants to dig deeper, we can query the slower log database but the user kind of expect that pulling the entire history of a record will take a bit longer than other operations.

Didn't read anything at first, just went and navigated/manipulated text and it worked as I would expect! This is a very nice VIM emulation!

I stopped using workflowy because it did not feel natural to edit a large amount of plain text outside of VIM.

That's great news, but I do not see quotas for SES in my dashboard and AWS service list.

Additionally, it seems they did not import previous requests in their new request history.

Resulto | Montreal, QC | Backend Developer | ONSITE

We are looking for a passionate developer who wants to join our software development team at Resulto. Your input will have a direct and measurable impact on the success of products frequently used by more 450 000 consumers.

You like to take initiative? You love web technologies but prefer to work your magic on the backend because that's your area of expertise. You want to work with experienced and dynamic colleagues? You are the perfect person to join our fantastic team!

To build our main product, we use:

- Backend: Python 3, Django, Django REST Framework et Celery - Frontend: ES6, Vue.js, Webpack, Bootstrap 4, SASS - Data: PostgreSQL, Memcached and Redis - Infrastructure: Ubuntu, Ansible, uWSGI, nginx, Terraform, Packer, AWS

We follow an agile development process and every person contributes to the continuous improvement of our processes and tools.

Working with Resulto has many perks:

- Contribute to the growth of a young company at a key stage of its evolution. - Relaxed work environment with a result-oriented and quality-driven culture. - Interesting technical challenges: software architecture, data mining, extreme configurability. - Flexible hours and telecommuting. - Competitive or friendly ping pong matches depending on your experience level! - And a lot more...

The ideal candidate will:

- Master a web programming language (+1 if you know Python, Ruby or Elixir) - Master a relational database (+1 if you know PostgreSQL or Oracle) and basic optimization and normalization techniques - Speak French or want to learn French

If you are interested, please email your CV to jobs@resulto.ca

We are using Wal-G in production and testing it every day by copying/restoring prod db to staging. The CLI is spartan, but it works and it's fast.

Andrey is also responsive if you encounter any issue and went to a lot of trouble to fix a hard to reproduce recovery issue we encountered.

Resulto | Montreal, QC | Backend Developer | ONSITE

We are looking for a passionate developer who wants to join our software development team at Resulto. Your input will have a direct and measurable impact on the success of products frequently used by more 450 000 consumers.

You like to take initiative? You love web technologies but prefer to work your magic on the backend because that’s your area of expertise. You want to work with experienced and dynamic colleagues? You are the perfect person to join our fantastic team!

To build our main product, we use: * Backend: Python 3, Django, Django REST Framework et Celery * Frontend: ES6, Vue.js, Webpack, Bootstrap 4, SASS * Data: PostgreSQL, Memcached and Redis * Infrastructure: Ubuntu, Ansible, uWSGI, nginx, Terraform, Packer, AWS

We follow an agile development process and every person contributes to the continuous improvement of our processes and tools.

Working with Resulto has many perks: * Contribute to the growth of a young company at a key stage of its evolution. * Relaxed work environment with a result-oriented and quality-driven culture. * Interesting technical challenges: software architecture, data mining, extreme configurability. * Flexible hours and telecommuting. * Competitive or friendly ping pong matches depending on your experience level! * And a lot more...

The ideal candidate will: * Master a web programming language (+1 if you know Python, Ruby or Elixir) * Master a relational database (+1 if you know PostgreSQL or Oracle) and basic optimization and normalization techniques * Speak French or want to learn French

If you are interested, please email your CV to jobs@resulto.ca

I wonder if this is a response to Amazon Lightsail[1] now offering managed database?

[1] https://aws.amazon.com/blogs/aws/new-managed-databases-for-a...

Relocating would be fine, but we cannot really help with work permit applications.

Resulto | Montreal | Full-Time | Onsite | Full-Stack Developer

We are looking for a passionate developer who wants to join our small software development team at Resulto in our office in Montreal. Your input will have a direct and measurable impact on the success of products used by more than 200 000 customers.

Our stack: * Backend: Python 3, Django, Django REST Framework et Celery

* Frontend: ES6, Vue.js, Webpack, Bootstrap 4, SASS

* Data/Cache: PostgreSQL, Memcached and Redis

* Infrastructure: Ubuntu, Ansible, uWSGI, nginx, Terraform, Packer, AWS

We follow an agile development process and every person contributes to the continuous improvement of our processes and tools.

Working with Resulto has many perks:

* Contribute to the growth of a startup at a key stage of its evolution.

* Work with a fantastic and experienced development team.

* Relaxed work environment with a result-oriented and quality-driven culture.

* Interesting technical challenges: software architecture, data mining, extreme configurability.

* Flexible hours and telecommuting.

* Competitive or friendly ping pong matches depending on your experience level!

* And a lot more...

The ideal candidate will:

* Have a good grasp SASS and JavaScript (+1 if you know Vue.js, React or Angular)

* Master one web programming language (+1 if you know Python, Ruby or Elixir)

* Have experience with a relational database (+1 if you know PostgreSQL or Oracle) and basic optimization and normalization techniques

* Have a good grasp of a distributed version control system (+1 if you know Git)

* Know how to use a server configuration tool (+1 if you know Ansible or Terraform)

* Speak French or want to learn French

Send your CV to jobs@resulto.ca and mention HN for bonus points!

We tried Zulip for a week but the team decided to not continue the experiment. I personally really liked the UI and the keyboard-centric workflow, but the lack of polished UI and the suboptimal mobile experience was really difficult to defend.

Another problem is that we would often end up replying to the wrong thread because of the way the general view is organized.

We are now trying Twist (https://twistapp.com) and it is a very good compromise between the efficiency of Zulip and the polished UI of Slack. The main advantage over Zulip is that you only see one complete thread at a time in the main column, but you can see the last message of each thread you've subscribed to in your inbox (second column): when you hit reply, you are certain that you are replying to the right thread.

"Don’t cache Django models"

This is too broad to be good advice. A typical solution to stale models is to increment a cache version key, effectively invalidating the old cache.

Version keys can be coarse- or fine-grained. For example, you may have one version key for the entire application (supported by Django by default) and one version key per model or application (you have to roll your own solution). If your app's models change, you can increment the app version key and the next time you try to fetch a model instance from the cache, you will miss and instead fetch the instance from the DB.

Resulto (resulto.ca) | Frontend Developer | Montreal | Onsite | Full-time

Do you usually take initiative to suggest high-value improvements and keep up to date with best practices? Are you passionate with frontend technologies, but not afraid to dive into all the layers of a complex system? Do you want to participate in all phases of development and influence the business direction of a young and successful company? You are the perfect candidate and we would love to speak with you!

We are a bootstrapped company producing the leading loyalty and customer satisfaction platform in the powersport industry in Quebec. Your work would directly impact more than 200 000 customers and users.

We at Resulto strongly believes that bringing new interns and employees to our team is a learning and growing opportunity for both sides. If this sounds interesting to you, email us at jobs@resulto.ca

Hi, I really liked your post and your comments about your experience with each provider, but I totally disliked your answer and the one below. I didn't see anywhere that your benchmark was only about hourly billing providers so I find your reply disrespectful. Maybe you should update the title or the text if you want to take such stance?

Moreover, to me, regular VPS == openvz and not hourly billing (openvz would also disqualify ssdnodes).

I am unpleasantly surprised that they do not mention why services that should be unrelated to S3 such as SES were impacted as well and what they are doing to reduce such dependencies.

From a software development perspective, it makes sense to reuse S3 and rely on it internally if you need object storage, but from an ops perspective, it means that S3 is now a single point of failure and that SES's reliability will always be capped by S3's reliability. From a customer perspective, the hard dependency between SES and S3 is not obvious and is disappointing.

The whole internet was talking about S3 when the AWS status dashboard did not show any outage, but very few people mentioned other services such as SES. Next time we encounter errors with SES, should we check for hints of S3 outage before everything else? Should we also check for EC2 outage?

I confirm for SES being down in US-East-1 :-(

I agree. That is why I mentioned our large test suite in my first comment.

Regarding typing errors in production, I meant that we never encountered an error that could have been directly prevented by a Java-like static type checker[1], e.g., a function with an int parameter that was called with a string argument.

We use types as a documentation tool so the noise you are talking about is actually very useful to us. When someone unfamiliar with the code wants to call a function, a quick look at the signature is usually enough now that we use type annotations. Before that, we provided that information in a docstring, which was more verbose so longer to write and longer to read.

We found PyCharm to offer a better out of the box validation experience than mypy (less configuration), but it's not perfect, i.e., we still see occasional false negatives and false positives. Ultimately, we did not include type checking in our build pipeline, but as the tooling becomes more mature, we will definitively revisit that decision.

[1] I know other languages have more powerful type systems that may have prevented some errors we encountered, but I don't have enough experience with these type systems applied to large systems to comment on that.

For our small team, we found that type annotations are useful as a substitute of documentation and it cut our docstrings at least by half. For most small and well-named API functions, we don't need docstrings anymore.

We're big fans of type aliases also. For example, API functions do not return an int, they return a PK. They do not return a str (or Text), they return a URL.

We're also heavy users of typing.Optional to mark parameters or return values that can accept and return None.

We tried mypy but it failed miserably on our large codebase and frankly, with our large test suite, we never had a typing error found in production so I think it's not a good investment of our time.

I'm eager to test type annotations with our next intern to see if it speed up the ramp up process.

We moved >1K$ hosting per month from them to StormOnDemand because of the lack of transparency on security issues, particularly the PagerDuty incident.

This was heartbreaking because Linode's value (performance, reliability, support, price) is almost impossible to match if your requirements fit their VM configurations.

But in the end, we did not want to risk another security or DDoS fiasco. We estimated that the risk was high that they would be targeted again, we could not believe their promises to get better at face value considering previous transparency issues, and we did not want to tell our customers that a company that had experienced security issues for the past three years had suffered from another attack[1].

They seem to have invested quite a lot in their networking infrastructure (kudos!), but I believe they still use their old coldfusion applications.

[1] Non-technical customers often ask us why we are not hosting on Amazon because they heard it's where serious companies host their servers (!). We used to explain why Linode was a more cost-effective choice, but Linode was not a nice name to google in early 2016.

That would be nice. If you know you have a trip coming in two weeks, you could register to get a apolitical facebook account with posts created every day with your virtual apolitical friends. You could optionally register for a twitter account that likes most of Trump's tweets or replies with "I love this guy" kind of message.

A few quick notes about our experience with Rsync.net

1. It is more expensive than S3/Glacier, but they offer "free" read-only snapshots, which can be very useful if your backup software or script does not perform its own snapshots.

2. It can be difficult to determine how much space is taken by the peculiarities of ZFS vs. your own data.

3. Although they offer subaccounts, it is not possible to know the disk usage of a particular subaccount.

4. If you have transfer speed issues, you can contact them and they may whitelist your IP (good if you are doing server backup, not useful for home backup on dynamic IP), which significantly increased speed for us.

5. They have a 10% "free" soft quota, mainly because it is difficult for mere mortals to know in advance how much space your backup will take on ZFS. They send an email when you reach the soft and hard quota.

6. You can communicate with a knowledgeable human by email. This has been helpful to diagnose small but weird issues we were facing.

7. Although we like S3 and Cloudfront, it's nice to have a backup location that relies on standard tool (rsync) and that is outside our usual providers/datacenters.

So after perusing the documentation, it seems that:

1. No cache. You need to build your own.

2. No obvious github integration. You can pull code from github but that's it.

3. Notifications are managed with SNS. So you need to use lambda or something like that for Slack Notifications.

4. No obvious ssh support. Would need to check the dockers image they use to be 100% sure.

I'm trying to find if they offer or plan to offer these features:

1. Caching. CircleCI and Travis cache intermediate build artifacts (e.g., virtualenv in python) to reduce build time.

2. Github pull request integration (red cross on pull requests if the build fails).

3. Chat integration. Sending a message to slack or hipchat when the build fails.

4. SSH into build container. Very handy for rare but difficult to locally reproduce build bugs.

Interesting offer though. We found that we would pay less than 5$ a month for our build needs and they would run concurrently.

But in the context of ec2, downtime must occur in two AZ at the same time to count IIRC. There is no single AZ SLA.

They advertise a 99.95% EC2 SLA. Does that mean that an instance in a single AZ can go down anytime for any length of time?

In vue.js, SEO is taken care of with with server side rendering[1].

This assumes that you are using node.js as your backend though.

[1] https://vuejs.org/v2/guide/ssr.html#SEO