pythonaut_16

I've been learning it an enjoying it so far. It's going a little slow for me due to my limited time to commit to it and being fairly different from OOP, but there are a ton of really powerful concepts and features in it.

The biggest thing holding me back is really just picking a project and getting some momentum going on it.

Those small things are actually the ideal use case for VMs.

Imagine wanting to spin up a new server so you go and buy that small tower, bring it back, and hook it up.

Now imagine using a VM where you literally go onto a webpage and click a button to provision the same amount of resources.

Additionally, most hardware sits idle most of the time. When you're using tons of towers, it's likely that most of them will sit under 50% load 90+% of the time. With a VM setup, the hypervisor can balance that better so you can get better utilization of your hardware.

How do issues like this happen? I'm fairly new to software development and I haven't really seen issues like this, and I'm having trouble thinking of what types of code would cause it.

I'm assuming it's usually related to things using multiple threads or at the boundaries of different programs communicating?

What if you put the FarmBot plotter on wheels or rails and let it move up and down rows of boxes?

I haven't looked a ton at its performance characteristics but I would imagine it spends a lot of time sitting idle with the current plot they're maintaining.

But a similar bot that could maintain 4'x8' boxes and then roll on to the next one could be interesting. Or even one that could manage continuous line of plots of a given width, e.g. 4' wide

I think there's a solid chance that Amazon will help drive down delivery prices, at least on the consumer end.

If they can use automated deliveries to lower their UPS/FedEx/USPS costs, and to help them beat Brick and Mortar prices, you can bet that they'll take full advantage of it.

Retail stores to would likely deliver some of the savings to customers because they have to compete with Amazon and other online retailers.

Check out the Thinkpad T400 series (e.g. T460s) and X1 series (e.g. X1 Carbon and X1 Yoga). They're lightweight and durable with big screens at pretty reasonable prices.

I have a Unifi AC Lite and I just use the power injector that came with it. I think for the non-pros they use a non-standard POE, but I'm pretty sure the Pro's can use either Ubiquiti or standard PoE equipment

My personal experience would suggest that this isn't a 60% allow workers telecommute whenever they want, but rather allow workers to telecommute sparingly when circumstances require.

Those are all intentional choices and benefits of Python

1. This gives you flexibility to structure your app in a way that makes sense for what you're doing. In addition, I've found Django's approach to modular apps to be far more manageable and approachable than Ruby's "all the controllers go in the controllers folder" approach.

2. Explicit imports is a Python thing and a huge benefit. I've looked at plenty of Rails code bases where I had no idea where different functions and variables were coming from. In Python/Django, you can always see the explicit definition at the top of the file.

3. The "crippled down" templating language is very intentional as well. Django is preventing you from writing your application in the templating logic (something I've seen too much of in Rails) All your template should be doing is specifying how the data is to be rendered in HTML/whatever.

Really Python/Django could be said to be Ruby/Rails flipped on it's head.

Ruby itself isn't very opinionated (there are usually several ways to do something), while Rails is.

Python itself is pretty opinionated (there should be one right way to do things), while Django isn't.

In general it's a matter of opinion and perspective but I personal find Python and Django to be much easier to work with than Ruby and Rails.

I would probably keep a running total as I read through each line, then store `line_number: running_total` in a dictionary.

At the end, return the highest key in the dictionary for your total, and then run a reduce that returns the first key/value pair that is >= half the total