Blog

Starter Project – Angular 2.0 + TypeScript + WebPack + Bootstrap

As Angular 2.0 is finally in Beta (¡Yeah!), it is playtime now. In my opinion, the best starter project to use (Feb 2016 ;-) is Angular2 Webpack Starter by AngularClass. Unfortunately, it does not come with Bootstrap support out of the box. This is typically not a major issue but many front-end developers will be faced with 2 major changes:

  • Grunt, Gulp and Bower are dead, long live NPM and Webpack
  • TypeScript rules but how do I "require" my CSS dependencies?
Therefore, I created fork of the aforementioned starter project adding Bootstrap support. Also, in order to customize your Bootstrap theme, I believe it is advisable to use either Less or Sass. As I am more familiar with Less, I added it to my setup as well.



Posted in Blogroll

Starter Project – Angular 2.0 + TypeScript + WebPack + Bootstrap

As Angular 2.0 is finally in Beta (¡Yeah!), it is playtime now. In my opinion, the best starter project to use (Feb 2016 ;-) is Angular2 Webpack Starter by AngularClass. Unfortunately, it does not come with Bootstrap support out of the box. This is typically not a major issue but many front-end developers will be faced with 2 major changes:

  • Grunt, Gulp and Bower are dead, long live NPM and Webpack
  • TypeScript rules but how do I "require" my CSS dependencies?
Therefore, I created fork of the aforementioned starter project adding Bootstrap support. Also, in order to customize your Bootstrap theme, I believe it is advisable to use either Less or Sass. As I am more familiar with Less, I added it to my setup as well.



Posted in Blogroll

Apache on OSX Yosemite

I was recently doing some web stuff on my laptop for the first time in a while. I could pull up the "It Works!" page, but nothing else.
This Apple forum post solved it.
Blogged here to help search results :)
Posted in Blogroll

Apache on OSX Yosemite

I was recently doing some web stuff on my laptop for the first time in a while. I could pull up the "It Works!" page, but nothing else.
This Apple forum post solved it.
Blogged here to help search results :)
Posted in Blogroll

Monday Night Rituals

Monday nights for me have a ritual on them now. I say now, but in reality they have had a ritual on them for several years now. Several years seems about the right amount of time to actually claim something as a ritual I suppose. It's for sure past the 66 days it takes to formulate a new behavior.


Anyways, the ritual is I meet up online at 10PM Eastern / 7PM Pacific time with a good friend of mine, Dan Gilkerson, and discuss "stuff". Mostly we chat about side projects we are working on, but it can range widely depending on what we've been involving ourselves with and who else is on the call. How do I lay out what this "stuff" is. A list would probably work best.

  1. Helpful patterns to use in meteor.js.
  2. What's a good name for our latest project idea (namecheckr is a fantastic tool to check name availability for this).
  3. Here's an idea similar to one we've had, and look someone has built a project around it.
  4. What's the latest thing Dan has learned in his latest hobby.
  5. What Kickstarter has peaked our interest lately.
  6. What's the next thing for XYZ side project we are tackling.
  7. ... A plethora of other things 
The Monday night meeting started out of a desire to make getting together and working on extra projects routine. Not only routine for us, but also routine for those around us. Being a married father of two, it can be hard to fit things in that don't revolve around the family. A routine Monday night meeting has helped in that endeavor. It's not that I don't love my family with all of my heart and enjoy spending time with them, I do.

Meeting later in the evening for me has helped with fitting things together. By 10:00PM we've gone to whatever after school activities are up for the day (soccer/dance/t-ball/kungfu), we've eaten, completed all homework, hung out, taken baths, and gotten the little angles that are my children down for bed. It gives me a good hour to decompress after the kiddos go down to sleep. My rule is to try to be done with the meeting by 11:00PM or 11:30PM at the latest so that I can still get a relatively good nights sleep.

I bring this up to say this. That if there is a side project that you intend to do, outside and beyond what you do in your day job, start with one simple ritual. Our Monday Night ritual is one of a series of rituals that I've put in place to try to make it to that next lilypad in the pond of life for getting some successful side projects flowing. You may ask, are they successful? Is anyone using them? Yes, some are. Not huge successes yet, but enough success to be able to watch people use the systems, which gives us feedback for what's next.
Posted in Blogroll

Monday Night Rituals

Monday nights for me have a ritual on them now. I say now, but in reality they have had a ritual on them for several years now. Several years seems about the right amount of time to actually claim something as a ritual I suppose. It's for sure past the 66 days it takes to formulate a new behavior.


Anyways, the ritual is I meet up online at 10PM Eastern / 7PM Pacific time with a good friend of mine, Dan Gilkerson, and discuss "stuff". Mostly we chat about side projects we are working on, but it can range widely depending on what we've been involving ourselves with and who else is on the call. How do I lay out what this "stuff" is. A list would probably work best.

  1. Helpful patterns to use in meteor.js.
  2. What's a good name for our latest project idea (namecheckr is a fantastic tool to check name availability for this).
  3. Here's an idea similar to one we've had, and look someone has built a project around it.
  4. What's the latest thing Dan has learned in his latest hobby.
  5. What Kickstarter has peaked our interest lately.
  6. What's the next thing for XYZ side project we are tackling.
  7. ... A plethora of other things 
The Monday night meeting started out of a desire to make getting together and working on extra projects routine. Not only routine for us, but also routine for those around us. Being a married father of two, it can be hard to fit things in that don't revolve around the family. A routine Monday night meeting has helped in that endeavor. It's not that I don't love my family with all of my heart and enjoy spending time with them, I do.

Meeting later in the evening for me has helped with fitting things together. By 10:00PM we've gone to whatever after school activities are up for the day (soccer/dance/t-ball/kungfu), we've eaten, completed all homework, hung out, taken baths, and gotten the little angles that are my children down for bed. It gives me a good hour to decompress after the kiddos go down to sleep. My rule is to try to be done with the meeting by 11:00PM or 11:30PM at the latest so that I can still get a relatively good nights sleep.

I bring this up to say this. That if there is a side project that you intend to do, outside and beyond what you do in your day job, start with one simple ritual. Our Monday Night ritual is one of a series of rituals that I've put in place to try to make it to that next lilypad in the pond of life for getting some successful side projects flowing. You may ask, are they successful? Is anyone using them? Yes, some are. Not huge successes yet, but enough success to be able to watch people use the systems, which gives us feedback for what's next.
Posted in Blogroll

The mystics are coming out

Discussion on the Scala collections revamp is starting to get mystical. It really bugs me: good language design makes a huge difference, but it's hard to see unless you actually deal with thousands or more developers on millions or more lines of code. Casual observers of language design discussions don't see it themselves, so they don't realize what these problems look like to the other people in the discussion. So they think everyone is just goofing around and throwing out random ideas just because they are possible.

I started to follow up on the issue itself, but I fear making the problem worse. So I'll post a couple of rebuttals here. I don't really think the people actually involved in the redesign will be distracted by the mystics, anyway. They are like gold-sellers in MMOs or beggars in San Francisco; unless you are specifically trying to engage with them, you just learn to tune them out. Well, okay, they are like really nerdy gold sellers who like to talk about higher math. Okay I better just drop this attempt at an analogy.

First, Python's indexing operator has a lot of practical problems. Here are a few concrete examples: https://plus.google.com/+MattMight/posts/BVSmNadKni4 . Thinking backward from those puzzlers, I think the root of the problem is that the [a:b] slicing operator means something different depending on whether a and b are positive, and whether a is smaller or larger than b. This is foundational syntax used everywhere, and if you want code to be readable, people need to know whether it's doing a forward or reverse slice without having to do mental data flow analysis on the parameters. Java avoids this trap, and Scala should, too. The sublist operation should only work on non-negative arguments, and only when the first argument is smaller than the second.

The other thing I will say is that exceptions, null, and -1 are also all fine, when used by a tasteful library designer. We tried at Semmle to get people using more Options, and we found that it harmed our reputation as a quality lint tool. I can only speak publicly about open-source code, but to give an example, Apache Spark has over a thousand occurrences where they use null but, with only local changes, they could use Option instead. It's too many. It means that the basic premise of the programming advice has some sort of problem.

As one stab at it--though it's really a huge topic--you have to think about what you want the callers to do to defend against a missing value. If Scala's basic get/apply methods starts returning an Option, then people will just litter their code with calls to .get, so the net result is that the code is more bloated but otherwise behaves exactly the same. Even in pure math, people will write notation like f'(x) as the derivative of f, but you know, derivative isn't always defined. So should smart mathematicians instead write get(f')(x)? Or (f') match { ... }?

That's my try, but you don't even have to understand this if you are willing to ape mature libraries in areas that they are working okay. It's not a practical problem in Java that the various .get() methods return null or throw exceptions; even if you say it's not perfect, it's certainly not bad. It is, however, a very big problem that Java collections are overly mutable. For example, see this Stack Overflow question: https://stackoverflow.com/questions/2842169/why-are-public-static-final-array-a-security-hole. Scala will be more attractive to more developers if it focuses on these widely recognized pain points. Which is why the mystics drive me crazy--if they get their way they will find that their playground is gradually becoming a ghost town, but only after it's too late.

Posted in Blogroll

The mystics are coming out

Discussion on the Scala collections revamp is starting to get mystical. It really bugs me: good language design makes a huge difference, but it's hard to see unless you actually deal with thousands or more developers on millions or more lines of code. Casual observers of language design discussions don't see it themselves, so they don't realize what these problems look like to the other people in the discussion. So they think everyone is just goofing around and throwing out random ideas just because they are possible.

I started to follow up on the issue itself, but I fear making the problem worse. So I'll post a couple of rebuttals here. I don't really think the people actually involved in the redesign will be distracted by the mystics, anyway. They are like gold-sellers in MMOs or beggars in San Francisco; unless you are specifically trying to engage with them, you just learn to tune them out. Well, okay, they are like really nerdy gold sellers who like to talk about higher math. Okay I better just drop this attempt at an analogy.

First, Python's indexing operator has a lot of practical problems. Here are a few concrete examples: https://plus.google.com/+MattMight/posts/BVSmNadKni4 . Thinking backward from those puzzlers, I think the root of the problem is that the [a:b] slicing operator means something different depending on whether a and b are positive, and whether a is smaller or larger than b. This is foundational syntax used everywhere, and if you want code to be readable, people need to know whether it's doing a forward or reverse slice without having to do mental data flow analysis on the parameters. Java avoids this trap, and Scala should, too. The sublist operation should only work on non-negative arguments, and only when the first argument is smaller than the second.

The other thing I will say is that exceptions, null, and -1 are also all fine, when used by a tasteful library designer. We tried at Semmle to get people using more Options, and we found that it harmed our reputation as a quality lint tool. I can only speak publicly about open-source code, but to give an example, Apache Spark has over a thousand occurrences where they use null but, with only local changes, they could use Option instead. It's too many. It means that the basic premise of the programming advice has some sort of problem.

As one stab at it--though it's really a huge topic--you have to think about what you want the callers to do to defend against a missing value. If Scala's basic get/apply methods starts returning an Option, then people will just litter their code with calls to .get, so the net result is that the code is more bloated but otherwise behaves exactly the same. Even in pure math, people will write notation like f'(x) as the derivative of f, but you know, derivative isn't always defined. So should smart mathematicians instead write get(f')(x)? Or (f') match { ... }?

That's my try, but you don't even have to understand this if you are willing to ape mature libraries in areas that they are working okay. It's not a practical problem in Java that the various .get() methods return null or throw exceptions; even if you say it's not perfect, it's certainly not bad. It is, however, a very big problem that Java collections are overly mutable. For example, see this Stack Overflow question: https://stackoverflow.com/questions/2842169/why-are-public-static-final-array-a-security-hole. Scala will be more attractive to more developers if it focuses on these widely recognized pain points. Which is why the mystics drive me crazy--if they get their way they will find that their playground is gradually becoming a ghost town, but only after it's too late.

Posted in Blogroll

#JavaOne2015

#JavaOne2015

My fifth JavaOne started today.  I attended a Java University class.  It was interesting to be on the other side of that sort of presentation.

Red Hat is well represented this year.  There is a microsite on Red Hat Developer.

Stop by the Red Hat booth in the vendor hall if you are attending.  We have presentations all day long, and there is a rumor about trucker hats...

The agenda at our booth this week:

Monday, October 26th

10:15 - 11:00 
Standardized Extension-Building in Java EE with CDI and JCA

- Jason Porter

11:45 - 12:30
Taming Microservices Testing with Arquillian Cube
- Aslak Knutsen, Alex Soto & Bartosz Majsak

1:45 - 2:30
Docker for Java EE Developers
- Rafael Benevides & Markus Eisele

3:30 -  4:15
Shenandoah: An Ultralow-Pause-Time Garbage Collector for OpenJDK
- Christine H. Flood
Posted in Blogroll

#JavaOne2015

#JavaOne2015

My fifth JavaOne started today.  I attended a Java University class.  It was interesting to be on the other side of that sort of presentation.

Red Hat is well represented this year.  There is a microsite on Red Hat Developer.

Stop by the Red Hat booth in the vendor hall if you are attending.  We have presentations all day long, and there is a rumor about trucker hats...

The agenda at our booth this week:

Monday, October 26th

10:15 - 11:00 
Standardized Extension-Building in Java EE with CDI and JCA

- Jason Porter

11:45 - 12:30
Taming Microservices Testing with Arquillian Cube
- Aslak Knutsen, Alex Soto & Bartosz Majsak

1:45 - 2:30
Docker for Java EE Developers
- Rafael Benevides & Markus Eisele

3:30 -  4:15
Shenandoah: An Ultralow-Pause-Time Garbage Collector for OpenJDK
- Christine H. Flood
Posted in Blogroll

AJUG Tweets

Follow @atlantajug on twitter.

Recent Jobs

    AJUG Meetup

    ‘system_date’,
    ‘orderby’ => ‘meta_value’,
    ‘posts_per_page’ => 1,
    ‘order’ => ‘ASC’,
    ‘category__in’ => array($cat_id)));

    if( $latest_cat_post->have_posts() ) :
    while( $latest_cat_post->have_posts() ) : $latest_cat_post->the_post(); ?>

    $value ) {
    echo “$value”;
    }
    ?>

    $value ) {
    echo “$value”;
    }
    ?>