I second Harvest as well. Been using it for several years and it's great. The native time tracking app that lets you start timers with a few key presses is handy.
I would 100% recommend you do _not_ use a spreadsheet or make your own software for this. Invoices are just far too important. Screwing up your time sheets, invoicing twice or forgetting to invoice would be horrendous. Harvest is only around $100 a year when you need the paid plan (it's always free for around 2 ongoing clients I think, the option is a little hidden). It might look simple enough that you could get away with a simple spreadsheet for example but Harvest makes it much harder to make mistakes (Did you put something in the wrong cell? Did you remember to mark an invoice as sent? Paid?) and a single mistake can be costly.
I'd love to know what "super fast" means. Are we talking about ETL jobs that would take hours? We run our batch file processing jobs in Python. It's not the fastest. But in a world where we can bring up more instances/containers to help process the work faster, I'd love to know how much faster COBOL is at these jobs that it'd be interesting to consider against the alternatives.
Thanks for the info. The Carbon looks really good, so it's good to know someone's already successfully put Linux on it without issues. Two questions: have you tried hooking up two monitors to it and if you connect an external monitor to the laptop and then close the lid do things work as expected?
I've tried that and it just feels incomplete. The VM competes for resources with the host machine. And then it's a bit awkward where the focus of the mouse is. When you run Linux natively you can get fancy with window/tiling managers (I really want to play with i3). Life is just better when things are simpler.
Evite | Los Angeles, CA | Python Full Stack Developer or Senior Frontend Developer | Full-Time | On-Site
We’ve got a small, but strong team solving problems at scale. There are lots of cool projects coming down the pipe, including a bit of real-time web work (yes, you can finally play with WebSockets). As it is, we’ve got a pretty varied mix of projects, including a bit of machine learning that we’ve currently been solving using Orange.
* Code stack: Python, Django, CoffeeScript (soon to be ES6), Backbone, Sass, Bourbon, ...
While what the AlphaGo team has accomplished is nothing short of amazing, I'm not sure if everyone's thinking about this in the right context. While playing there's a "super computer" behind the scenes with these specs 1,920 CPUs and 280 GPUs [0]. Then consider all the machines used to train this neural net. I'd say Sedol's brain is pretty freaking powerful. Also, with that much computing power I would expect AlphaGo to win with the right team and the right approach to solving the problem. It would be very interesting to change the rules and limit the processing power of the computer playing a human.
You can make AlphaGo stronger by adding machines, you can't make Sedol stronger by gluing more gray matter in his brain (yet I guess). So yea, efficiency is nice but so is scalability, and that's why this is exciting.
Also in a few years AlphaGo could be running on your cellphone. The chess AI Stockfish runs on an iphone today, and cellphones from what I could find online, uses less power than the brain (brain is roughly 20W, iphone has 1.4Wh battery which even if stockfish drains in 1 hour, is still 1W of power consumption)
Give it a few years and we'll all be saying "of course computers can play Go, but at least they can't <Insert task humans are still good at>"
These CPU/GPUs are doing very inefficient digital simulations of analogue processes. If anything, human brain has significantly more 'processing power' than Alpha Go when you restrict the computation to the activation of linear threshold units.
Evite | Los Angeles, CA | Python Full Stack Developer | Full-Time | On-Site
We’ve got a small, but strong team solving problems at scale. There are lots of cool projects coming down the pipe, this is probably not the right venue to get into much too much detail, but let’s just say we’re looking into PubSub, WebSockets, and push notifications. We’ve got a pretty varied mix of projects, including a bit of machine learning that we’ve currently been solving using Orange.
* Code stack: Python, Django, CoffeeScript (soon to be ES6), Backbone, Sass, Bourbon, ...
This is the first I've heard of Falcon. Have you used it for a "real" project? It'd be interesting to know the tradeoffs when considering it against something like Django Rest Framework. Looking at the benchmark figures on the Falcon site, it's sad that Python 3 underperforms Python 2. I wish Python 3 had the slightest performance win, it'd be an easier sell. Hate to shift the topic to Python 2/3 talks, but I've wanted to switch for a while now, and it's still not the simplest sell.
Yes I have used Falcon extensively and I like it alot.
Lies, damn lies and benchmarks - I'm not saying the benchmarks are made up but you know - the benchmark thing.
Falcon for REST API development. Django/Pyramid for full featured web application development.
And regarding speed, well how does its Python 3 performance compare to the Python 2 performance of other Python web servers? And any does speed matter that much? In many cases "fast enough is good enough" and the bottle necks are more likely to be other parts of your system and if speed matter that much then you should be horizontally scaling.
And if I may raise the ugly topic - who cares about Python 2 under any circumstances? For me - and I know many people do not think this way - Python 2 is dead so who gives a rats arse anything about it. Python 3 is the future and I'm not looking back for any gripes or grumbles about it.
Don't get me wrong, I think ruby-rails-slow is a bad thing, but Falcon fast should be good enough.
And if speed really matters to you then you shouldn't be using Python for web application development.
I looked into Falcon a while back - looked interesting but it wasn't immediately obvious what I would get over Flask (if nothing else, there's a tonne of Flask docs out there these days).
In all my research over the years Pyramid is the framework that looks the most interesting. The docs are amazing (I more or less read them cover to cover, even though I haven't tried the framework) and the whole thing seems very well thought out.
I'd love any insights from people who have worked with it.
I've worked on one project with Pyramid extensively, and I've been relatively pleased. It gives you a lot of flexibility, which can be good and bad. There is useful code that helps you unit test your app, and it is not a particularly opinionated framework. That being said, the number of options that pyramids allows can be a little overwhelming -- it gets a grade 'C-" when held up to the zen of python's line: "There should be one-- and preferably only one --obvious way to do it." When held up to "Although practicality beats purity.", as well as most of the rest of the pythonic ideals, Pyramids gets a solid A.
Personally, I'm excited to explore flask more, since it seems to put the ball entirely in your court. I like the concept behind flask a lot -- for some projects I'm willing to sacrifice additional framework features in exchange for a more careful understanding of everything I am adding to my app.
Yeah I mean it's hard to digest comments like "it's not a particularly opinionated framework" against things like "put the ball entirely in your court". They seem to be saying the same thing except you have a different perception of each when you say it.
The problem as I see it is that Pyramid has a lot of extra interfaces and support for things in the core by default (and some concepts that are completely missing from most frameworks like context). So much is there that it's easy to lose sight of how little is actually required. Fundamentally you can write Pyramid apps in 10 lines of code exactly as you would with Flask but that's less interesting for bigger apps and so the docs focus on all the extra features.
I mean if you take the example at the top of http://docs.pylonsproject.org/projects/pyramid/en/latest/ and add in the pyramid_jinja2 library via config.include('pyramid_jinja2') then you basically have views and jinja2 rendering fully baked.
As in the previous example if you get right down to it Pyramid doesn't even have a templating engine! Flask comes with jinja2 built-in! So scaling DOWN to APIs where this is not necessary is an interesting thing..
It's a matter of conceptual load, not about the actual capabilities. By "putting the ball in your court" I mean to say that flask adds an insignificant amount of conceptual load, and the overall difficulty to read and understand your app will be based on what you decide to add beyond flask.
By saying "it's not a particularly opinionated framework", I mean to say that it allows you to add, easily, whatever you want to it. However, there is a fair amount of conceptual load in doing so. The difference between a flask app and a pyramid app with pyramid jinja2 built in is that one of them takes about 20 seconds to understand.
Don't get me wrong -- I think pyramid is fantastic. But it it is disingenuous to suggest that there are not differences in complexity between the two frameworks.
"just building an API" does not mean you need something more lightweight. It means you have different requirements from a standard full stack web application. You are not dealing with cookies, forms or template rendering but you are still dealing with lots of other problems including authentication, authorization, headers, etc. Pyramid is the ONLY framework I've ever seen that comes with builtin support for dispatching to a view function based on more than just a request method (GET vs POST). In Pyramid GET vs POST is equivalent to any other request property including accept headers, cookies, query strings, etc. Any of these can dictate a different callable. See http://blog.delaguardia.com.mx/pyramid-view-configuration-le... for some examples.
Well as one of the primary maintainers of Pyramid I'll just say that it's laughable to me all the comparisons to Django as it's much more similar to Flask. The main difference is that it comes with several more "pay only for what you eat" standardized interfaces that you can use to pull things together. It's declarative security concepts are fantastic and completely missing from most other frameworks as well which choose to punt this part to (usually) half-baked addon libraries built to serve one specific use-case.
>> it wasn't immediately obvious what I would get over Flask
Falcon gives you less than Flask, not more.
For me the big thing is that Falcon has none of the stuff needed for building web apps. Flask has all that stuff cause it was built when back end servers also built the HTML pages. There's alot of stuff associated with that functionality in Flask that is not there in Falcon. It makes it much cleaner.
I think you have that backwards. Python 3 has been dead in the water since it broke backward compatibility. It's slower. It still only has about 20% of Python 2's use. Most active development of software is still in Python 2. There hasn't been a single killer feature of Python 3 to justify breaking compatibility without deprecation. The Py3 Dictator has already had to back down once on "discontinuing" py2 which was supposed to happen in 2015. If he insists on preventing a smooth transition that doesn't require libraries and significant code change then he will just end up with a permanent split as PyPy, Cython or Conda take over Py2 maintenance.
Most people did not use Windows ME or Windows Vista. Py3 is the ME/Vista of Python. A foisted inconvenience with little benefit. I still haven't heard anyone articulate a benefit other than "it's the future of Python!" Yeah, OK. But it certainly isn't the future of programming in Python until Guido makes an XP or 7.
I'd take those benchmarks with a massive pinch of salt. 338µs per request for Flask is the bad case. 0.5ms of the request is spent in the framework, that's not even noise. The fastest framework I've used is one I wrote for coldfusion and that's the only time I've expected all my requests to be sub 100ms. And even then, the network latency turns that into noise.
Look at features before performance - both in the case of frameworks and version of Python to use (Python 3 is a lot nicer).
