We are a community of pragmatic software development professionals who care about creating well crafted software.
Aim - To have a community of professionals that contribute to collective growth.
The focus of this community is to organize talks, roundtables & trainings that increase awareness and skill around practices like pair programming, TDD, & others. We intend to discuss software craftsmanship practices and values with a wider audience.
We are technology agnostic and invite all software craftspeople to join.
From the manifesto:
"As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
@16:00 -- But aren't the functions passed to higher order functions objects too? If a lambda is the name for an object of an anonymous inner class that implements a "single abstract method" interface, then it is obviously an object. Isn't it? But we tend to call it a "function" coz the function is the predominant component of the lambda content Please comment? (even though I know there is 0.1% probability for you to see this comment) :)
Principle 2 is really bad and shouldn't be used. You should NOT use maps for all your data structures, this will totally kill your performance. Sure, for small data sets you wont see a recognizable difference, but if you have a lot of data performance will be very poor. So this leads to software beeing not scaleable at all. There are of course valid cases where you need maps. But don't just represent all of your data with generic data structures.
encapsulation and abstraction are related .. he meant that that the details of how it's done is encapsulated and not accessible to the consumer of the api .. he can only access the exposed methods and that's important if they later decided to change anything in the implementation your code will not be affected and doesn't even know about it ... and in the end is abstraction too
