Just back from AngularConnect 2015 in London (October 2015), and I’m enthused about all the great new stuff in Angular 2.
Only problem is, everything has changed and I’ve only just got the hang of Angular 1.
So, while I prepare to launch my new Angular/Firebase front-end to Luzme which uses Angular1, I want to start skilling myself up with Angular 2, for the next major release.
So this is my plan: take it step-by-step, and write about each step so I can share with others on the same journey, and learn from the comments and questions along the way.
This is the plan
At each step, I will write a failing test which introduces the next step.
I will commit that test, so you can see how to write such a test.
I will blog about what the step is and why it’s necessary. And what I needed to do to make the test pass.
I’ll commit that as a tagged version in github, so you can see at each step how to get from A to B.
Here’s the repo:
So you want to start a startup but can’t get past the first hurdle. You can’t decide on your startup idea. You have too many ideas and don’t know how to choose one. Or you have one great idea, but something always gets in the way of you executing it. Sound familiar?
The answer is simple. Pick One. Work on it. Learn from it.
Your idea will be wrong, almost certainly. That shouldn’t stop you doing it. How will you get experience without making mistakes?
“Good Judgement Comes with Experience; Experience comes from Bad Judgement” 13th century, via Mark Suster, Jim Horning and others
As my old music teacher used to shout at our chorus, when we sang quietly because no-one really knew the piece: “Sing Louder! How can I tell you you’re wrong if I can’t hear you”.
The only sure way to fail is to not start. Start singing louder so you can hear your mistakes!
Upgraded to Django 1.8 and now you get this error when you run your tests?
Have you created migrations for all your apps? If not, you may well be hitting the problem that the database tables are being created in the wrong order, which will give you this error.
If you have an existing Django 1.7 or earlier project, then you need to create the initial migration files, and then fake the initial migration, as described here
Create the migration with
$ python manage.py make migrations your_app_label
And then fake the application
$ python manage.py migrate –fake-initial your_app_label
If you change the site URL in WP, it’s possible to lock yourself out of the admin site by virtue of a redirect loop.
If you’ve got access to the database, you can revert that change. If not…
You can update wp-config.php to override those settings; WP_HOME and WP_SITEURL.
Found this useful summary in Ask’s reply:
Group (runs in parallel): Error on one task does not stop the others
Chain (runs in serial): Error on one task halts the chain
Chord (group with callback): Error in group prevents callback from firing
Update: From Celery 3.0.14, this Chord behaviour is configurable. See CELERY_CHORD_PROPAGATES config option.
I was deeply sad to hear of the untimely death of John Pinner.
I met John at PyCon UK a few years ago, and very quickly learnt a great respect for him as a man, a friend, a mentor.
I saw him but once a year at the annual PyCon UK conference, and yet he had a great effect on me; I can only imagine the huge void that will be left by his passing for those who knew him more closely.
RIP John. I’m glad you were part of my life.
Currently available at $39 and upwards (May 2014)
Check the current live price at Luzme
Meteor is a new web framework which promises near-real time data updates on the client.
If you’re planning to learn how to learn Meteor (which you should, it’s awesome!), you need this book “Discover Meteor”.
Continue reading Review: “Discover Meteor”,Tom Coleman & Sacha Greif
For example, ‘15,99 EUR’
See whether you have the right locale installed.
$ locale -a
$ sudo apt-get install language-pack-es
$ sudo dpkg-reconfigure locales
And then in the code, you can do this
myprice = unicode(locale.atof(myprice))
I’ve been wanting to migrate away from django-registration for a while.
Yes, I know it’s been the default registration package since forever and I’ve used it happily for many years. But :
- it’s no longer actively maintained
- I want to do away with the email confirmation
- I want to allow login using either email or username
So after a bit of googling, I decided to try out django-allauth, and I’ve just finished the migration.
Here’s some notes for anyone else thinking about doing the same.
I’ve got an existing system:
Note: I’m only setting up the ‘accounts’ side of the allauth package, I’ll leave the social-accounts for later.
So here’s what I did:
- Set up django-allauth as per their documentation at http://django-allauth.readthedocs.org/
- Removed the django-registration module from the settings
- I wanted to use my own templates rather than theirs, so I added an account subdirectory into my accounts/templates and copied theirs over from the package. I needed to ensure that their package was called later in INSTALLED_APPS to make sure my templates were found first.
- Mostly the templates just worked by changing my copy of their templates to use my base template, and other cosmetic changes
- One minor gotcha was that the django-registration login template uses id_username as the field, whereas django-allauth uses id_login (since it can be either username or email)
- By default, allauth will produce a message for every action. Their base template displays these. I decided I didn’t want them; so following their instructions at http://django-allauth.readthedocs.org/en/latest/index.html?highlight=templates#messagesI replaced the provided templates with blanks.
- I added a redirect url from the old django-registration /accounts/register to the new django-allauth /accounts/signup
That was it. Much easier than I expected.
And the answer is…