Chat with documents
Coding
WordPress Content generator
Image generators
Course generation
Audio recordings into searchable notes and text
npx create-react-app my-app
Single Responsibility
One job per class as much as possible, so changes in behavior are more granularly isolated.
Open Close
Open for extension, close for modification.
A class interface, or a parent class defines the base blueprint, extending it encapsulates differences in behavior between children of it
You find yourself writing a long series of “if” statements, or a big switch case, inside a parent class. Try to encapsulate the functionality in classes instead
if (something = x) { then do y}
if (something = z) { then do a}
etc…
better expressed as:
class x {
do y
}
class y {
do a
}
and make that a “spawn the right class” problem, the object contains its own different behavior
Liskov Substitution
Each class has a series of “contracts” attached it it. Which translates to methods should have pre conditions and post conditions.
For example, let’s say class A, has a pre-condition where it only takes arguments of the Z kind.
Along comes its subclass, and this one (wrongly, violating this principle) takes arguments of the Y kind as well.
This weakens the parent contract, and if you were to substitute the parent with the child anywhere in the code, now you are open to code failing, because you though object of the parent class will only take Z arguments, but this sub class is making it possible for them to take Y arguments.
The same can happen with the output: the parent class has a “contract” with the world out there, where it will only output float numbers, but now comes a subclass that allows int returns. The parent has been diminished, and results can break stuff because we can’t just plug and play the subclass with the parent contract anymore.
Interface Segregation
If you make your interfaces too broad, you will find yourself forced to implement methods you don’t need, for certain clients.
Abstract with interfaces, but don’t force clients of them to implement things they don’t need. Let the client dictate the segregation of the interfaces.
It is better to have a bunch of them, client specific, than generic ones that force extra code.
Dependency Inversion
Interdependency modules: at some point there will be a one to many relationship on them
Say, function A has three different ways to pull the data it needs internally. And say it is taking an argument to deal with that:
functionA(dataPuller){
if(dataPuller typeOf some){ pull the data this way}
if(dataPuller typeOf some){ pull the data that other way}
etc…
}
The above will be better off refactor as:
functionA(someSubclassThatImplementsAbstractClassThatDealsWithDataPulling){
someSubclassThatImplementsAbstractClassThatDealsWithDataPulling.pullData();
}
The advantage: when you add / substract / edit the ways you pull data, you do it on the abstraction, you don’t need to modify anything in functionA. So function A is not thighly coupled to this data pulling business, it just use it (whatever it is).
Best, possibly fastest DB for key value kind of data
Imperative becomes a series of instructions, on how to get to the desired outcome
Declarative tells up front what the end state is (think map or reduce functions)
http://testdrivendevelopment.ourownjava.com/jmockit/how-to-test-private-methods-using-jmockit/
Example at:
http://angularstrap.onsubject.com/
http://angularstrap.onsubject.com/demo.html
Check-in under experiments/angularStrap_example in bitbucket
Modals
<button class="btn btn-primary" bs-modal="modal">Show Modal</button>
And then, in your controller:
$scope.modal = {
title: 'Modal Title',
content: 'Modal content'
};
Tooltips
<button class="btn btn-link" bs-tooltip="tooltip">what's this?</button>
And inside your controller:
$scope.tooltip = {
title: 'Tooltip Title'
};
Alert
<button class="btn btn-primary" bs-alert="alert">Show Alert</button>
Your controller:
$scope.alert = {
title: 'Title',
content: 'Alert content',
type: 'success'
};
You can also instantiate the bootstrap functions via services:
controller('demoCtl', function($scope, $alert){
var alert = $alert({
title: 'Alert Title!',
content: 'Here\'s some content.',
type: 'danger',
container: '#alertContainer',
show: false
});
});
All things you can do, from the source:
Put together:
https://bitbucket.org/ramrod/tutorials-rails-angular
From the source:
https://thinkster.io/angular-rails/
In action: