721 karma · joined October 9, 2010
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.
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.
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.
I stopped using workflowy because it did not feel natural to edit a large amount of plain text outside of VIM.
Additionally, it seems they did not import previous requests in their new request history.
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
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.
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
[1] https://aws.amazon.com/blogs/aws/new-managed-databases-for-a...
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!
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.
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.
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
Moreover, to me, regular VPS == openvz and not hourly billing (openvz would also disqualify ssdnodes).
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?
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.
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.
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.
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.
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.
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.
This assumes that you are using node.js as your backend though.