| d=[]as Date | |
| print('Christmas') | |
| for(;d.month-11||d.date-25;d+=1)print(' Eve') |
| assertThat("Avoid squid:S2699 false positive.").isNotBlank(); |
When working with mutable objects, I often instantiate some object and subsequently call mutator methods to populate its state. I find this both boring and smelly.
Consider the following (admittedly contrived) unit test:
@Test
public void primary_org_is_most_precise() {
Set orgs = new HashSet<>();
Overall, Java's compiler is an impressive piece of software (not nearly as impressive as the JVM, though) that has no doubt saved me from countless hours hunting down runtime issues. Nevertheless, there are times when the compiler makes me sad.
if (obj instanceof Foo) {
((Foo) obj).foo();
}TBD
Texas Hold'em except that one extra card dealt to each player on the deal and per flop. Players must discard a card from their hand each round so that they have only two cards before betting.
Michael Feathers @mfeathers https://twitter.com/mfeathers/status/994661651466010624
Inheritance might be the most unjustly maligned language feature. The amount of effort that has been expended at the language level to tame it over the decades has been extraordinary. Java dropped multiple inheritance and offered interfaces to cut away some hazard. Scala introduced traits; Ruby introduced modules.
But you can use inheritance safely if you just follow a few guidelines.
After suffering java.util.Date and Calendar for many years, Java 8's new Date/Time API was a welcome and groovy addition to Java SE in and of itself. Groovy's upcoming 2.5 and 3.0 release, however, makes it even groovier.
To follow along with the examples, you will need to download either Groovy 2.5-rc1 or Groovy 3.0-alpha-2 (or later releases in those 2.5 or 3.0 lines). Date/Time API-related features are not in Groovy 2.6 as that version is intended to be a Groovy 3.0 backport for Java 7, which predates the Date/Time API.
Groovy's great operability with Java means that the on and now factory methods for the various types within the java.time package can be used to create instances, but there are now some Groovy-specific alternatives.
| def good = 'acdejklmps' | |
| def illegal = 'abcdefghijklmnopqrstuvwxyz' | |
| good.each { illegal -= it } | |
| def goodWords = [] | |
| // download a dictonary, e.g. https://github.com/dwyl/english-words/blob/master/words.txt, and save to file | |
| new File(/C:\dev\temp\words\words_alpha.txt/).eachLine { word -> | |
| if (!illegal.find { word.chars.contains(it) } | |
| && word.length() > 2 | |
| && !(word.chars as List).intersect('aeiouy'.chars as List).isEmpty()) { |
| // using a coustom keyvalue String per element of the Stream | |
| Map<String, String> map = Stream.of("key1:value1", "key2:value2") | |
| .collect(Collectors.toMap(str -> str.split(":")[0], // key function | |
| str -> str.split(":")[1])); // value function |
Our organization is in the midst of a push to improve the state of unit testing. I had thought I communicated the need for unit testing well and explained its importance sufficiently, but I attended a meeting recently that made me realize I still had much work to do.
The IT organization is largely driven and managed by non-developers. Our processes regard developers as "resources" who are procured, managed using rigid enterprise-wide processes, and expected to produce features. As such, code is not well-understood beyond the tacit acknowledgement that code needs to be written in order to build a feature. The fact that code accrues, that a unit test written during a user story has benefit for the development of future stories, and that overall code quality has a signficant impact on a team's ability to enhance a system safely and productively is largely lost in the sea of contracting and project management best practices. Sure, there's