Sometimes you need to find the expected format of dates in your PostgreSQL database. You can find the database’s default style using your psql console:
#Log into the postgresql console
#connect to your database
#interact with your database
Run entire Rspec File
CMD + SHIFT + T
Run specific test or block (where cursor is selected)
CMD + SHIFT + R
Providing public and private design patterns in Angular.js
The concept of Encapsulation is an important design pattern in most object-oriented programming designs. Determining which properties and methods should be accessible is a nice forcing function because it forces the programmer to think about how his or her could will be consumed.
Encapsulation is typically achieved by defining local variables within the function object. These locals can only be referenced by other functions defined on the function object.
What about AngularJS?
I find myself thinking a lot about what should be exposed publicly in my view controllers. As a beginner, it’s easy to just attach your functions and variables to $scope (or this if using `controller as` syntax) and call it a day. But do you really need your view to have access to all of those functions? In most cases you don’t. Instead, assign these private functions or values to a local variable within your controller function.
I often define a function that initializes the default values within the controller.
We need some way to re-serialize this object’s keys to camelCase after a response is received. Similarly, requests made to the server should be translated to under_score like the server is expecting. Fortunately the Restangular library makes this quite easy to accomplish.
Restangular allows you to add response and/or request interceptors which allow you to modify your data before and after a $http request. Using the Humps library to camelize and deCamelize, it was simple to modify the requests and responses handled by Restangular. Simply add a config block and use the provided RestangularProvider to add a responseInterceptor and a requestInterceptor:
ActiveModel::Serializers gives you a lot of flexibility and modularity when it come to generating JSON for your Rails api. Serializer just work when the serializer is named after the model it references ( MyModelNameSerializer). You also knew you could easily extend a base ActiveModelSerializer using class inheritance MyExtendedSerializer < MyModelSerializer. Recently, however, I found myself building a serializer that couldn't be named by ActiveModel::Serializer convention and couldn't inherit from the base serializer for that class.
So where does this gem find it's dependent class?
It turns out that the method Serializer#model_class, defined on Serializer defines this behavior.
It was relatively simple to override this behavior: Just override this method in your serializer so that the class method model_class refers to the parent class.