My experience of Agile
- Client: How long will this take?
- Me: Hmm, probably 2-3 days
- Client: No, in story points
- Me: Wha? Oh, erm... 20?
- Client: No, it has to be a Fibonacci number
- Me: Wha? Er, ok... 5?
- Client: Thanks
- ...2 days later...
- Client: Remind us how long this will take?
- Me: 5 points!
- Client: No, in days - we can't use story points for budgeting
- Me: *headdesk*
Connect404 - Simpleweb Rusic Hacknight
Last night was another superb Simpleweb hacknight - this time we were hacking away with their social platform Rusic.
What is Rusic?
Rusic is an insanely powerful and flexible web platform for creating socially-powered web apps - complete with social login, voting system, data storage, CRUD, theming, CDN asset hosting and deployment.
It also uses Shopify’s Liquid templating language and has a superb API so it is both simple and flexible - suffice to say there is little you cannot build with it!
The brief for the hack was pretty open - simply to leverage Rusic in whatever way you could think of.
Our idea
I joined forces with the excellent David Darnes and Rob Rhoades (who, incidentally, was Simpleweb’s first remote hacker!) to build our idea: Connect404.
We wanted to make a 404 Rusic theme that you could have your website redirect to if/when someone encountered a missing page on your website.
The 404 page would then collect the referring URL that led to the missing page and log this ‘error’ in Rusic, thus turning it into an error log.
Meanwhile, to incentivise the user to submit an error report and make the page more fun/interesting, we decided to create a web version of Connect4.
After logging in via Twitter/Facebook, you can then pick a column to place your token and try to ‘connect 4′. As an added bonus, your social profile avatar and link were added to each token you placed.
We had hoped to implement red/yellow turn taking, real-time updates and animated tokens dropping in, and detecting a win but 3 hours was too tight :)
Behind the scenes, the tokens were essentially just a uniquely styled list view of 'ideas’, stacked using flexbox.
You can see a demo of how far we got at connect404.rusic.com, which we were chuffed won us 3rd prize of £40! :)
The competition
There was an amazing turn out and so many innovative uses of Rusic, really highlighting just how powerful and flexible it is.
1st prize went to an awesome automated iOS app builder build in Python, 2nd went to an app that generated music from text - and Adam even began building a Dropbox clone!
Thanks
In closing, just wanted to say a big thank you to Simpleweb and the gang - they really know how to host a hacknight: free beer, soft drinks, snacks and delicious dinner courtesy of George.
Also, thanks especially to Ben Reid for providing support for Rusic (and dev in general) throughout the evening.
Well done all involved and roll on the next one! :)
Today I learned something pretty scary about Google Apps - if your domain expires and is purchased by somebody else, they can takeover your account and gain full access to pretty much everything associated with it (emails, calendar, docs…).
As it turns out, a Google Apps account (not to be confused with a Google Account) is tied to a domain, not a user. Lose the domain, lose the ownership…
But the scary thing is that the new domain owner can use a DNS record to prove ownership and reset your password…
This happened to me today - luckily with an old and dormant Google Apps account that had zero activity.
I began receiving “new sign-in” notifications for this particular account which immediately gave me the jitters.
Then, when I went to login and check “recently used devices”, I found that the password had been changed and I was locked out. Google’s help documentation sent me in circles but I eventually I was able to send an email to support.
Meanwhile, I did a WHOIS lookup on the domain and contacted the new owner to find out if they had any insight. Again, luckily, they were really helpful and explained to me that a client of theirs had bought the domain and wanted Google Apps setup. By following this guide, they were able to takeover the account with all the historical data that was associated:
https://support.google.com/a/answer/80610?hl=en
I can certainly understand a scenario where a NEW Google Apps account would want to be created when a domain changes hands - but that the DNS can circumvent a password in an existing Google Apps accounts seems like a really worrying security vulnerability.
I don’t know about you, but I am having a search through legacy Google Apps accounts and either deleting them or ensuring my auto-renew settings are on…
But seriously, WTF, Google?
Update 27/07/2015: contacted Google about this and they have indicated that it is “expected behaviour”… which is pretty astounding:
We are aware of this situation, and the account was working as intended (as per Help Center article: https://support.google.com/a/answer/43315?hl=en), when you created the Google Apps account using that domain the Google Apps is linked to the domain and if you loose the domain the point 1.3 of the Terms Of Service, is mentioned that: “1.3. Customer Domain Name Ownership. (…) If Customer does not own, or control, the Customer Domain Names, then Google will have no obligation to provide Customer with the Services.” (Please check this at : http://www.google.com/apps/intl/en/terms/reseller_premier_terms.html), as I have mentioned we are working to have the security stronger on this cases, but at the moment this is an expected behavior.
I am not sure when “no obligation to provide services” became “allow someone to circumvent the password and gain access to data”.
It does not seem they see this as a significant security concern so I just suggest keeping on top of your domain renewals - or deleting dormant Google Apps accounts.
Update 05/08/2015: contacted by new owners of domain - Google are now threatening to delete their account due to a breach in their security terms… not only is this too late, it just makes the situation worse as the new owners have invested time and, now, data in the new account. Have contacted Google…
Styling components within components
When building a pattern library, one of my goals is to write code that is lean and solid but also obvious - as a freelancer, it is key that the code I hand over has a low barrier to entry for future developers.
In particular, I want other devs to be able to quickly and easily recognise situations when changing the style of one component could negatively impact another, without having to go hunting through the library and code.
A classic example is when a component exists inside another component, and needs some overriding, context-specific styles. Where should these styles actually go?
Take, for example, a component called .driver which needs to exist in a modified state inside .header - my particular preference comes in two stages:
- Styles that override the .driver are applied via a context modifier .driver–header
- Styles that relate to context but do not modify .driver itself (e.g. position) are applied to a context wrapper .header__action
Check out the example pen: http://codepen.io/iamkeir/pen/Nqzjbz?editors=110
With the above, .driver styles are kept in one place, making it easier to see how changes to one variant can affect another. Meanwhile, specific styles for layout that are almost irrelevant to the .driver itself, are kept separately in the .header context.
(Note, I try to avoid ‘component collide’ where you end up with two seemingly unrelated classes on the same element, e.g. .header__action.driver–header)
This approach is by no means infallible; you still need to be mindful of brittle context styling - but keeping styles in a contextual location certainly gives developers a helping hand in mitigating the risks.
This is my favourite approach at the moment - how do you handle scenarios such as this?
(Hat-tip to @taholder for showing me the merits of obvious code over clever code back when I was a fledgling front-ender)
