1
point
funkydata
Joined 77 karma
http://twitter.com/#!/funkydata
- funkydata parentThat comment made my day. I actually had an intern like that!
- So, actually, on the museum's ticketing site they say that the internet tickets are sold out, but if you actually get there, there's a limited amount of tickets that are sold each day (because not everyone uses the internet) : "Merci de noter que des places pour la visite le jour même sont en vente chaque jour directement à l'accueil de l'exposition, dans la limite des places disponibles.".
- Yes, you can. It has to be where there is templating language of course (you cannot put a breakpoint on a arbitrary div for example), you can also debug the rendering of the template through Pycharm if you want to in order to have a full stack debug, but I'm used to doing that using the browser developer tools.
- Well, as previously stated in Pycharm and Visual Studio (not tested on others) there is. If I remember correctly, both will install their requirements remotely and then allow you to do so. However, I would not recommend it:
- you will probably forget to clean up after the fact leaving you with both performance and security problems
- you should never debug in production, use something like Sentry instead also, better to replicate the production environment in a sandbox (either on your machine using Vagrant or Docker, etc. if feasible) or in the cloud by taking a snapshot of your production environment and using it as a sandbox to debug (and then of course destroying it after use).
- Also, do not forget to integrate with Sentry [https://sentry.io/] or something that does the same thing.
It will also keep you sane.
- If you try to keep everything in one app, you'll have gigantic views.py, models.py, etc.
Nobody wants to work with those. Also, a simple typo in those files can bring your whole system down and can make it hard to debug.
Apps, are a cheap (EXCEPT when you HAVE TO [but really, do you? Really?] move models between apps) way to keep YOU sane.
- Although it goes against certain opinions AND if you set a norm for their use, signals are the way to go.
You can either decide that signals code will live in the app where the objects reside or the app of the target objects and that's it. A built-in and simple interface between objects.
- 1 point
- 1 point
- I've decided to play it simple albeit "old school" (because Docker seemed to add its own set of headaches - also not every project needs to do micro services or work with clusters or scale):
- Vagrant (so you don't have to worry about runtime executables) with the stack matching that of the production server (you can even ask ops to provide you with the provisioning script and remove the parts that you don't need - otherwise learning to provision your dev. VMs won't hurt you)
- Virtualenv
- pip
Then simply point your IDE (I only use Vim under duress) to the remote Python interpreter (the one you installed in the Vagrant VM).
It does add processing overhead but it worked with my 2010 MacBook Pro until it died and still works (only ten times faster) with the 2016 model. Your only limitation would be the RAM (I would recommend at least 8GB and if you plan to run multiple machines communicating together as much as you can afford - I do believe that Docker has less overhead, but again, for my use, not needed).
The best practice is what works for you, not the latest trend.
- Why don't you just use Windows with the included Ubuntu subsystem?
- 1 point
- The Django ORM for example.
You can ever traverse relations and still use the same syntax: https://docs.djangoproject.com/en/2.0/topics/db/queries/#loo...
- I'm still using/programming and typing on my 2010 17 inches MacBook Pro.
The keyboard still works perfectly whereas my acquaintances that have bought newer models have had the keys falling, failing, discolour and whatnot.
That and the ineffable mate screen and screen size.
I've changed the memory, the hard drive and the battery to keep going and it's still going, albeit with more fan noise.
I'm really afraid/don't want to switch to a new/lesser MacBook Pro.
- >Smaller but hi-dpi, and with far greater color accuracy and brightness. Also, you can hook up an external monitor, apparently lugging 17" beasts around wasn't popular enough to carry the models forward.
Size on the screen does matter, I'd rather the screen do the work than my eyes.
With a 17 inches I don't need to hook up an external monitor. I am able to work at full proficiency anywhere.
>Actually way way more. Less varied ports (basically 2 types: 4 USB-C and 1 headphone), but way way more I/O power and connectivity.
If you don't mind paying for and carrying around a dozen dongles. Also no ethernet port. And you're forgetting about the ExpressCard slot...
- Also @beat forgot to say "matte display". MATTE. Mine is a 6 year old 17 inches MBP and I still use it for everything.
It's still current. I can also rip CDs with it (it is handy children) :)
I've even found a VERY simple way to dual boot Windows 10 on it after trying to get the instructions I found everywhere to work (after Apple made sure it was indeed difficult).
I even play games on it.
To me it was the reference developer laptop and still is.
I would pay as much as $5000 for a 17 inches Retina Matte MBP, the same SSD speed as the TouchBar models, the Pascal chipset, an 8 core i7 and 64GB of RAM and I do not think I am alone in that category.
- There is not blackmailing from Apple. They are offering him a chance to wipe his slate clean if he publicly (since he was the one to go public) acknowledges that what Apple did was justified (and it was).
He has to now decide what's more important: his pride or his revenue (https://web.archive.org/web/20150103225308/http://blog.kapel...), it's that simple.