Recently we developed an angular application for one of our Multinational clients with the purpose of helping them to manage accommodation, transfers and flight times. This app had to deal not only with dates but also time and we looked into many different date and time pickers created specifically for angular in order to deal with that. We ended up selecting angular-bootstrap-datetimepicker as our choice.
At first hand everything went fine but during development the daylight saving period started here in Ireland and we noticed the dates being stored in the server started to differ of what we were picking in the app by one hour.
We didn’t want the application to be timezone aware, we wanted the users to pick a date on the datepicker and store that date made of the “numbers” that were picked. No smart conversions or anything like that.
In order to achieve this behavior we had to add moment-timezone which gave us support to deal with timezones and then changing the code of angular-bootstrap-datetimepicker in the following way:
On the datetimepicker.js file, on the function setTime, one line after case ‘moment’ we added moment.tz.setDefault(“Etc/UTC”) in order to enforce the timezone to UTC every time we are setting a date.
By telling the datepicker to use moment we started to have issues with the angular filter for dates, which simply stop working, so we added another library called angular-moment to deal with that. So the code for the input that shows the date ended being this:
Further action: Doing some more testing we discovered that by using moment.utc() we don’t really need add moment-timezone or do the setDefault(“Etc/UTC”) thing. We have not given this a huge amount of testing, but the code would look like this:
We recently announced QuickDBD, a simple product we made for drawing database diagrams by typing. If you take a look at the QuickDBD app you'll see it converts source code into a diagram. What we needed to make this work was obviously a parser.
- we would have complete control over how the parser works
- everyone here is very well versed in JS
- Jison was new to everyone and there is a bit of a learning curve in being able to do stuff with it efficiently
- it felt as if we were fighting Jison to make it work something it wasn't supposed to more than it felt it was this great tool that was would empower us to do things better and faster
- a couple of times it was pretty hard to get information on how to do something with Jison so we had to fall back to reading it's source code to figure things out
- it didn't feel like the right tool for the job
We however did pick up some ideas from trying it out and I believe it made the custom parser we came up with that much better. We wrote a parser that's fairly small, fast and easy to read, expand and fix - which is ultimately what we needed.
I still think Jison is a great tool but it just wasn't a very good fit four for our needs. If you're considering using it, perhaps try it out on a smaller subset of features of your language first and see how you like it before committing to it. You can always go back to writing something custom after you tried it out.
I also recommend you read this very good parser generators vs custom parsers SO thread with pros and cons for both sides.
Hope this helped!
Recently we had a small debate about Angular2 and what the benefits and pitfalls of using it for a project right now would be. In the end Fabrizio and I came up with a short list of pros and cons.
- Typescript will force developers to write better code.
- Angular2 should be faster than the Angular1.
- It is best not to invest in a framework if it is to be shortly discontinued.
- You will be one of the Angular2 pioneers.
- The development process will be very strict and it will require a good knowledge of the project.
- Localization of application will be easier with the implementation of the shadowDom.
- Debugging templates will be easier because they will raise runtime exceptions.
- The code needs to be built before deployment. This will slow down the process but will spot code errors and typos.
- Gaps between browsers implementations of new standards will be handled by specific libraries (Angular2 will emulate the shadowDom).
- It is in an Alpha version. It means that the inner structure could (and it will) be subject of big breaking changes.
- The API is not stable yet (breaking changes will be introduced).
- Not all features are implemented yet (you will have to reinvent the missing parts and then once they get officially implemented, your custom workarounds will be obsolete and probably not as optimized and not as good as Angular2).
- Not enough documentation. Also not enough code examples on the web, so much work will be pioneering.
- Ecosystem is not there yet (not all libraries and tools are ported yet). For example: there is an alpha of Bootstrap; Foundation isn’t there yet; the router is not ready yet. The lack of availability of convenient libraries may mean more development.
- Both versions will remain on the market and both of them will be actively developed.
- The team is still thinking about "how to do things for Angular2".
So that's what we came up with. Of course there is no ultimate answer and surely Angular2 will be a good tool once it's ready. But before that happens, we think it's probably best not to use it for serious projects that need to go into production.
Speaking of framework readiness here is an appropriate comic from Commitstrip that hits the spot.
Here are some things I like this week. Broad category here:
Designs, Art, Libraries. I know I'm just linking here, but a
lot of interesting things came past my inbox/reader this
Portfolio. Found this site today. Very unique design and
typography. The blog has a nice collection of photos and design
related things. Their portfolio is also very impressive and
presented in an unusual yet very usable fashion. They designed
the Facebook logo!! Very Cool.
2011. I highly recommend visiting one of the exhibitions for
this. It ends this weekend, so get out quick and snap up some
The Role Of Design In The Kingdom Of Content.
It's true now more than ever - Content is King. This article goes a
great job explaining why great content needs to be supported by
great design. Let your designs support your content, rather than
Regardless of what your content actually says, the design around
it controls what the users see first and how their eyes move across
the sections of the page.
gmail-like favicon notfication library, and all done with
And finally, because it seems the world cannot have enough
Designed to work seamlessly with data from the Open Source
Exchange Rates API project - but can be set up to use any data
source and base currency in just a few lines. And it works as a
NodeJS/CJS and RequireJS/AMD module, too. Yay!