I did not hire a remote developer, but I worked as a remote developer. Following are the issues which I faced, and probably my hirer would have experienced. If the spec is given orally, then there will be lot of confusion. So, you need to give mock-ups and/or detailed stories. In case of any doubts, the time to fix the confusion is drastically more in a remote developer. Personally, I believe that all people should be committed as much as the founders and share the same values as that of the company. This will be less with a remote developer.

Sebastian Which in-memory DB would you recommend. We have filters based on date as well.

j : why you need those objects in memory? because the solution we need is time critical. and why some of the filtering cannot be pushed to SQL? filtering can be pushed to SQL. But loading the filtered data back to memory would take time as the size of objects is of the order of 10 million. does it happen once or 200 times. this happens in bursts. ie, in a day, the requests will come back to back for atleast 10 times per user. couldn't you just serialize it on apache spark for a distributed map / reduce ? we have not tried this. this could be a solution. Problems which we face now Loading of objects to memory on restart of the software is more than cceptable. Our current implementation was part of the Prototype, now we are facing scaling issues.

Hi, I am Roopak, Backend Engineer, DevOps engineer, Python trainer :P. I love solving problems, and am a product guy. Based out of Kannur, Kerala, India, currently working with Surewaves MediaTech, Bengaluru, India. Tech Stack I work on: Python/Django REST, Java/Hibernate, NodeJs, C, PHP.

I would prefer a Docker. Main reason which I prefer Docker is that you can have multiple apps with different environments running in the same machine. Eg: If you 2 apps - one which requires Node1 and the next which requires Node 4, then with only PM2, you will not be able to deploy both on the same server. Dockers help you in that. There can be 2 dockers having different versions of Node and still running on the same machine.

If the packages are small, then the build time will not be an issue. But, if packages are large like OpenCV, Pandas, Numpy, etc, then every change in the file - build time will be huge everytime.

When I said manually, I meant, it will be part of Docker file. Yes, it would be a little hassle to maintain both requirements.txt file and Dockerfile, but, to optimise the build time, I feel that installs should be part of Dockerfile. I have similar approach for package.json also. Any change in package.json/requirements.txt file will trigger download and install of all the packages, which I feel is a bad way to build a Docker.

I follow a combination of both. I maintain a requirements file for the reasons you mentioned. And, I install packages individually to optimize my build time.

Super cool editor. I have seen similar on in Dropbox paper. I think you guys forked out from the same project.

There are 3 ways. Way 1 - Write an entrypoint script. invoke cron. Command to run your scripts. Pros: Crons goes together with your docker image = Less headache, Cons: Not inline with Docker concept of "one duty per one docker instance". Way 2 - Run cron as part of the host Cron job will be a docker run command. Pros: Goes inline with Docker concept of "one duty per one docker instance". Cons: Take care of setting up docker command on host. Way 3 - Use schedule jobs (in Kubernetes) Pros Goes inline with docker concepts Kubernetes script takes care in all your deployments. I am now following Way 2 - because, I want to align with Docker concepts. Also, since I am planning to move to Kubernetes (or Docker Swarm), this strategy will help me in migration. I am not using Kubernetes in production, because of company deadlines and the learning curve there. Ideally, I feel that schedule jobs should be used to solve Crons. In Schedule jobs, a docker instance is created for the job and removed once the task is done.