Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "choosing is hard"
Mother of god, choosing a topic for today's security/privacy blog post is hard!
I have too much choice 😅24
TL;DR: I'm stressed out over choosing a side project because of the commitment and fear of failure :(
I'm a student and summer vacation starts in 3 days (and actually has already started for me, thanks to a "smartly planned" hospital stay), so I'm currently looking for a cool project to start. This will be my third summer vacation during which I want to make complete a project, and I never actually did it. The first year, I couldn't think of any reasonable, doable project which would be interesting and fitting for the time scope (I was quite new to programming back then, so I probably couldn't have done things that would be interesting to me, an any project that I could've done would just take 20 minutes, cause I wouldn't understand anything more complex). The second time, I chose a project too big with too much new things I had to learn on the go. I actually pushed through for nearly a week, but then I realized that I only completed like 25% in that time, so I lost my motivation, thinking I could never finish it, while not wanting to start a complete new project, because that would've felt like wasting the time I put into my first project. It was still a valuable project and I learned a lot by doing it, but this year I want to actually finish a project; so I'm really stressed out right now trying to come up with a good project.
Usually I have millions of vague ideas in my head, but as soon as it comes to choosing, every single one seems to be the wrong one, or I forget about all of them. Everything that kinda interests me seems way to big and complicated to me, but I sometimes feel like I'm just underestimating my abilities, but on the other hand I have ~25 projects on my hard drive, of which 4 or 5 are finished and most will never be finished. :/
And it's just so overwhelming to choose something like that, because on one hand I really want to do a bigger project that I actually finish, and summer vacation is the only time I have so much time to code, and I love coding, but on the other hand choosing such a project that I will work 2-3 weeks on is too much commitment and also I'm anxious about failing it and never finish it, just abandon a buggy mess. Am I the only one to feel that way, or are you too having problems choosing side problems?
And, I guess if you have any ideas for a suitable project (literally anything, so that I might be exposed to some new ideas), just comment it.14
Linux is my kryptonite. I tried 4 different distros with Gui and Cli, tried a DVD, a USB, a hard drive, tried to install it as a primary OS (actually sacrificed my windows and all my stuff) and it still hangs up somewhere between choosing additional software and looking for hard drives. Sometimes life sucks15
*Looking for free advice*
I'm going to buy a MacBook Pro.
I'm having a hard time in choosing whether I should buy 2015 one or the 2016 one. Is not having enough ports really such a big issue?
Also, is there going to be a new MacBook Pro launch at the WWDC? :p5
A very long rant.. but I'm looking to share some experiences, maybe a different perspective.. huge changes at the company.
So my company is starting our microservices journey (we have a 359 retail websites at this moment)
First question was: What to build first?
The first thing we had to do was to decide what we wanted to build as our first microservice. We went looking for a microservice that can be used read only, consumers could easily implement without overhauling production software and is isolated from other processes.
We’ve ended up with building a catalog service as our first microservice. That catalog service provides consumers of the microservice information of our catalog and its most essential information about items in the catalog.
By starting with building the catalog service the team could focus on building the microservice without any time pressure. The initial functionalities of the catalog service were being created to replace existing functionality which were working fine.
Because we choose such an isolated functionality we were able to introduce the new catalog service into production step by step. Instead of replacing the search functionality of the webshops using a big-bang approach, we choose A/B split testing to measure our changes and gradually increase the load of the microservice.
Next step: Choosing a datastore
The search engine that was in production when we started this project was making user of Solr. Due to the use of Lucene it was performing very well as a search engine, but from engineering perspective it lacked some functionalities. It came short if you wanted to run it in a cluster environment, configuring it was hard and not user friendly and last but not least, development of Solr seemed to be grinded to a halt.
Elasticsearch started entering the scene as a competitor for Solr and brought interesting features. Still using Lucene, which we were happy with, it was build with clustering in mind and being provided out of the box. Managing Elasticsearch was easy since there are REST APIs for configuration and as a fallback there are YAML configurations available.
We decided to use Elasticsearch since it provides us the strengths and capabilities of Lucene with the added joy of easy configuration, clustering and a lively community driving the project.
Even bigger challenge? Which programming language will we use
What we’ve noticed during researching various languages is that almost all actions done by the catalog service will boil down to the following paradigm:
- Execute a HTTP call to fetch some JSON
- Transform JSON to a desired output
- Respond with the transformed JSON
Actions that easily can be done in a parallel and asynchronous manner and mainly consists out of transforming JSON from the source to a desired output. The programming language used for the catalog service should hold strong qualifications for those kind of actions.
Another thing to notice is that some functionalities that will be built using the catalog service will result into a high level of concurrent requests. For example the type-ahead functionality will trigger several requests to the catalog service per usage of a user.
To us, PHP and .NET at that time weren’t sufficient enough to us for building the catalog service based on the requirements we’ve set. Eventually we’ve decided to use Node.js which is better suited for the things we are looking for as described earlier. Node.js provides a non-blocking I/O model and being event driven helps us developing a high performance microservice.
The beauty of microservices and the isolation it provides, is that you can choose the best tool for that particular microservice. Not all microservices will be developed using Node.js and Elasticsearch. All kinds of combinations might arise and this is what makes the microservices architecture so flexible.
Even when Node.js or Elasticsearch turns out to be a bad choice for the catalog service it is relatively easy to switch that choice for magic ‘X’ or component ‘Z’. By focussing on creating a solid API the components that are driving that API don’t matter that much. It should do what you ask of it and when it is lacking you just replace it.
Many more headaches to come later this year ;)3