tag:blogger.com,1999:blog-38278762091716440672024-03-13T13:52:42.580-04:00Bigler On CodeMy name is James Bigler. I am a software developer. This blog is mostly a collection of links related to software programming and technology.James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.comBlogger732125tag:blogger.com,1999:blog-3827876209171644067.post-72863437140969574562015-09-04T09:18:00.002-04:002015-09-04T09:18:45.049-04:00Akka.net bootcampThe <a href="http://www.wrox.com/WileyCDA/WroxTitle/Patterns-Principles-and-Practices-of-Domain-Driven-Design.productCd-1118714709.html" target="_blank">DDD book</a> I am reading has a section on <a href="http://www.reactivemanifesto.org/" target="_blank">reactive systems</a>. Searching about reactive systems led me to the <a href="https://github.com/petabridge/akka-bootcamp" target="_blank">Akka.net bootcamp</a>. When my head starts pounding from reading too much DDD stuff, I start going through the bootcamp lessons. They are a lot of fun, and I feel like I learning some stuff about Akka. Not sure I am ready to use Akka at work but I bet in 5-10 years people will come to me and say "Why didn't you integrate our bounded contexts through Akka instead of NServiceBus?".James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com1tag:blogger.com,1999:blog-3827876209171644067.post-37582552024486829212015-09-04T09:14:00.002-04:002015-09-04T09:14:22.217-04:00Bounded ContextsHave a project coming up at work where we are going to create a separate DDD bounded context and integrate it with another bounded context. I have been reading a bunch of books to try and figure out how I want to do this.<br />
<br />
<br />
<ul>
<li><a href="http://info.thoughtworks.com/building-microservices-book" target="_blank">Building Mircoservices</a> - This was a really interesting read and I learned a lot of useful stuff</li>
<li><a href="http://www.enterpriseintegrationpatterns.com/" target="_blank">Enterprise Integration Patterns</a> - This one is considered the bible of integrating through messaging frameworks. It felt it bit like reading an encyclopedia. Maybe I shouldn't have tried to read it end to end and instead just used it as a reference.</li>
<li><a href="http://www.wrox.com/WileyCDA/WroxTitle/Patterns-Principles-and-Practices-of-Domain-Driven-Design.productCd-1118714709.html" target="_blank">Patterns, Principles, and Practices of Domain-Driven Design</a> - I am still reading this one. I would say this book is somewhere in between the other two books. Not a light fun read but full a useful stuff and not quite as heavy as an encyclopedia.</li>
</ul>
James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-84256428519829747912015-04-18T07:28:00.001-04:002015-04-18T07:28:44.355-04:00Possible way to covert part of JS application piecemeal<div> <br> I like how they limit to three components and limit how those components interact.<br> ---- <br> <b>Introducing T3: Enabling Large Scale JavaScript Applications | Box Blog</b><br> <a href="https://www.box.com/blog/introducing-t3-enabling-large-scale-javascript-applications/">https://www.box.com/blog/introducing-t3-enabling-large-scale-javascript-applications/</a><br><br></div><div><br><br><div><br></div></div>James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-40123020158217772542015-03-07T10:07:00.001-05:002015-03-07T10:07:19.857-05:00Samza<div dir="ltr">This article describes something that sounds like CQRS and Microservices in terms of database concepts.<div><br></div><div><a href="http://blog.confluent.io/2015/03/04/turning-the-database-inside-out-with-apache-samza/">http://blog.confluent.io/2015/03/04/turning-the-database-inside-out-with-apache-samza/</a><br></div><div><br></div><div>This is really smart since the people that would mostly likely resist this type of architecture change are the people that are most invested in relational databases.</div></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-63245389163154721872015-03-07T10:03:00.001-05:002015-03-07T10:10:08.217-05:00Nativescript<div>
This is allows you to write native apps with JavaScript. Very cool.<br />
<br />
<a href="http://docs.nativescript.org/getting-started.html">http://docs.nativescript.org/getting-started.html</a><br />
<br />
Would be interesting to compare this against<br />
<br />
<a href="http://www.reactnative.com/">http://www.reactnative.com</a><br />
<br /></div>
James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-55024894988964335922015-01-22T19:12:00.001-05:002015-01-22T19:12:45.303-05:00Riot – A React-like, 2.5K user interface library<div dir="ltr">I saw this posted on Hacker News. Looks very nice and simple.<div><br><a href="https://muut.com/riotjs/">https://muut.com/riotjs/</a><br></div></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-81447418357704686892014-11-04T16:25:00.001-05:002014-11-04T16:25:33.579-05:00Next Version of C#<div dir="ltr"><div>Watched this video about the next version of C#.</div><div><br></div><div><a href="http://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B345">http://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B345</a><br></div><div><br></div>We could use the code introspection features to validate our coding standards. Also the nameof operator could be used in FluentNhibernate for mapping properties so when you rename your properties your mappings update.</div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-21399532060571127402014-04-08T12:57:00.001-04:002014-04-08T12:57:50.701-04:00CQRS AppendixI finished the Appendix on CQRS in the book <a href="https://vaughnvernon.co/?page_id=168">Implementing Domain Driven Design</a>.
<p>
I really liked the appendix. It was written by a different author, and he provided very detailed code and explanations. There is even an <a href="https://github.com/Lokad/lokad-iddd-sample">example project</a> on github.
<p>
I searched for my more information about the author and found a blog post where he mentioned <a href="http://geteventstore.com/">Greg Young's Event Store</a>. I didn't know this existed but it sounds pretty cool.James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-49752172433951931582014-03-28T12:24:00.001-04:002014-03-28T12:24:53.971-04:00Connecting people when they have no connectionThis is an awesome idea.
<br>
<br><a href="http://www.wired.com/gadgetlab/2014/03/apple-multipeer-connectivity/">http://www.wired.com/gadgetlab/2014/03/apple-multipeer-connectivity/</a>
<br>
<br>
<br>
<br>Viva JDA! Join us at JDA FOCUS April 27-30 in Vegas! Register now at <a href="http://jda.com/FOCUS">jda.com/FOCUS</a><<a href="http://now.jda.com/2014-FOCUS-TextLink.html">http://now.jda.com/2014-FOCUS-TextLink.html</a>>James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-68328003945659873752014-03-17T09:10:00.001-04:002014-03-17T09:10:51.261-04:0014 chapters down one appendix to goI finished Chapter 14 on the Application of <a href="https://vaughnvernon.co/?page_id=168">Implementing Domain Driven Design</a>.
<p>
We have had the "What should go in a Application Service and what should go in a domain service" discussion here at work many times. At one point, the author claims I am going to clearly answer this question for you. I thought great I won't have to stress about that anymore. I feel like a broken record saying this but ... I was hoping he would give more details in his explanation because it still doesn't seem clear to me. What I got from what the book is that Application Services are for handling transactions and security. If you are doing more than creating an entity and adding it to a repository then you may have a "significant process" that needs to be modeled in the domain. He talked a little about Application Services that are for querying. I couldn't find any rules of thumb though about when your queries have too much business logic and should be domain services themselves. He did mention that sometimes you need to convert your application service into its own bounded context. I can think of one place in our code that might benefit from this idea.
<p>
There are no more chapters in the book. There is an appendix about CQRS written by someone else which I plan to read, but for the most part I am done with this book. I can't say I enjoyed reading it. I was really hoping it would answer a lot of questions for me, but I really don't think it did. I did some learn some things but not a whole lot. I guess the author's writing style just doesn't fit with how I learn. He probably knows a lot of stuff that can help me, but whatever reason I just didn't get that information from this book.James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-42382397441264663222014-03-11T08:23:00.000-04:002014-03-11T08:23:49.502-04:00Bounded Context IntegrationI finished Chapter 13 on Integrating Bounded Contexts of <a href="https://vaughnvernon.co/?page_id=168">Implementing Domain Driven Design</a>.
<p>
In our domain everything is jumbled together in one giant bounded context. Having never done what the author describes I found this chapter very interesting.
<p>
I liked the discussion about messaging. I had never thought about messages arriving out of order. I thought the author came up with a very simple solution to what could be a very complicated problem.
<p>
I also liked the discussion where he modeled a long running process as an entity and setup trackers to do automatic retries. I had to do something similar with a third party service our application integrates with. The code I wrote was very specific to the one area I was working on though. If you did this type of integration in multiple places in your application, then I could see that having more generic reusable components could be very helpful.James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-20090737559220779222014-03-04T21:33:00.001-05:002014-03-04T21:33:36.366-05:00Article about Javascript Promises<div dir="ltr">This is cool.<div><br></div><div><a href="http://www.html5rocks.com/en/tutorials/es6/promises/">http://www.html5rocks.com/en/tutorials/es6/promises/</a><br></div></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-57424752869085257462014-02-09T14:41:00.000-05:002014-02-09T14:41:03.913-05:00Finished repository chapterI finished Chapter 12 on Repositories of <a href="https://vaughnvernon.co/?page_id=168">Implementing Domain Driven Design</a>.
<p>
I thought the discussion he had on the performance benefits of Toplink was interesting. I remember having a similar discussion a while ago where we considering using stateless sessions for our readonly web services. This isn't quite as good as the Toplink design since even on our write operations we typically read data we don't intend to modify to do various types of validation.
<p>
I was little surprised he supports use case optimal queries which from what I can gather is using sql to create DTOs or value objects and returning them from your repositories. I would have thought he would only recommend that in cases of extreme performance problems. He did say if you are doing it a lot then it is probably a code smell.
<p>
He also has a section about Type hierarchies and how you should limit use of them. I tried implementing a Type hierarchy in NHibernate and it didn't go well for me. He had some good ideas about how to hide the types inside the aggregate and how to not let them leak out to be used by other aggregates.
<p>
I was also surprised he didn't give an example of how to test a repository with a mock. He did give an example of how to test with a real database and with a stub though.James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-2246693229452422712014-02-05T21:17:00.001-05:002014-02-05T21:17:21.632-05:00Machete's top 10 software booksSaving this list for when I am looking for my next book<span></span><div><br></div><div><a href="http://feedly.com/e/RP4QrQdf">http://feedly.com/e/RP4QrQdf</a><br></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-40275443823932640272014-02-04T08:42:00.004-05:002014-02-04T08:42:27.082-05:00The rules of aggregatesI finished Chapter 10 on Aggregates and Chapter 11 on Factories of <a href="https://vaughnvernon.co/?page_id=168">Implementing Domain Driven Design</a>.
<p>
I remember talking about Large Cluster Aggregates with one of my coworkers when we first started trying DDD. We didn't call them Large Cluster Aggregate at that time we just had two opposite ways we wanted to design our aggregates. We worried that if we didn't use large cluster aggregates then we would have an Anemic Domain Model. We felt like if we did use them then we would run into some bad transaction/performance problems. Erring on the side of caution we chose not to use them so I was happy the author also recommended not using them.
<p>
I also remember us discussing whether to reference everything by identity or by the entity. Even though we have a coding standard that says reference by entity I still think we reference by identity at least 50 percent of the time. I always preferred identity but I never had a really good argument of why. I think referencing by identity does make it more difficult to build up the data needed to generate a UI. For example a UI displaying a list of articles should probably display the author's name and not the ID of the author. When referencing by identity this usually means you need to query all the author's and then join them back with the articles in memory to create the DTOs needed for the UI.
<p>
The author talked with Eric Evans, and they came up with a good rule for when to be transactionally consistent and when to be eventually consistent. If it is the job of the person making the request to make the two aggregates consistent then be transactionally consistent. If it is someone else's job to make the two aggregates consistent then be eventually consistent. This mirror's what happens in real life and makes sense to me. When you get married your HR person does not instantly change your tax withholding while you stand at the altar. You change your tax withholding at some reasonable time in the future.
<p>
The author also mentions to not inject repositories or domain services into Aggregates. Even though the topic is heavily debated at my work we are currently not injecting repositories into Aggregates. We do in some cases though pass services into our aggregates using a Double Dispatch technique. Unfortunately the author does not give a lot of detail into why he recommends you don't pass repositories into Aggregates. I wish there was a book or pdf that had all the generally accepted good DDD practices and a short explanation of why it is a generally accepted good practice. Maybe things aren't that black and white though.
<p>
The one thing I took away from the factory chapter was that he recommended using factory methods instead of separate factory classes. I have never been a big fan of our factory classes since they seem to just initialize the properties on our classes and do very little work. I think mostly I just don't like calling a method with 10 parameters. Half the time you can't figure out what those parameters mean without drilling into the factory. What does that 5th parameter that is null represent? I guess the factory methods could reduce some of those parameters. I also like the idea of using the builder pattern instead of factory if you have a bunch of optional parameters.
James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-35515381567710414612014-01-27T08:00:00.000-05:002014-01-27T08:01:01.158-05:00Blog post about A/B testingI like this idea<span></span><div><br></div><div><a href="http://feedly.com/k/1mNosx2">http://feedly.com/k/1mNosx2</a><br></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-13755803001999568712014-01-20T08:18:00.003-05:002014-01-20T08:18:55.015-05:00Show me the codeI finished Chapter 8 on Domain Events and Chapter 9 on Modules of <a href="https://vaughnvernon.co/?page_id=168">Implementing Domain Driven Design</a>. I liked the author's explanation of how to integrate two different bounded contexts using events. He gave a couple different options like setting up a REST feed of events and also using a third party messaging tool. I thought both examples were clear and easy to follow.
<p>
He also mentioned you could use events to hook your domain to your application layer and also use events to hook up different components within your domain. He gave an example he called contrived for hooking the domain to the application layer. It was basically a method on an aggregate that did nothing but raise an event which was caught by an application service that added something to a repository. It wasn't very helpful to understanding the concept he was trying to explain. Also there were no examples of how to use events inside your domain model. I thought I might get more information by downloading his source code, but I checked the java and .net versions and their were no examples there either.
<p>
I am also reading the Big Nerd Ranch iOS book. I was struck the other day by the difference in the author's styles. In IDD the author starts with a lot of details about what he is trying to explain then sometimes follows that with a snippet of code that may or may not help explain his theory. By contrast the Big Nerd Ranch book starts out with a bunch of code that you can compile and run. The Big Nerd Ranch author warns you that you probably won't understand what you are typing but urges you to type it anyway. Once you have a working example they then go back and explain what you typed. I like the Big Nerd Ranch style much better. I can digest the theory a lot better if I can look at the actual code. I think in some ways I read code better than I read English.
<p>
The modules chapter was pretty thin. The one thing I got excited about was when he said not to create a separate folder for each component like factories, repositories, value objects, etc ... We have this Services folder that I don't like because it groups all these random services together that are in no way related. Later in the chapter he did say you could have a separate model and services folder if you treat your services like a thin layer between the domain and application. I am guessing though he still wouldn't recommend dumping all the services in there. Instead you still need to break that folder up into submodules if you have more than handful of services.James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-64239365722378522042014-01-17T18:55:00.001-05:002014-01-17T18:55:54.512-05:00Awesome talksFor when my head hurts too much to read<span></span><div><br></div><div><a href="http://feedly.com/k/1eXBg1h">http://feedly.com/k/1eXBg1h</a><br></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com1tag:blogger.com,1999:blog-3827876209171644067.post-45133929858693372062014-01-15T15:16:00.001-05:002014-01-15T15:16:58.595-05:00Georgia Tech online masters degree for CSPretty cool<div><br></div><div><a href="http://feedly.com/k/KjmKXI">http://feedly.com/k/KjmKXI</a><br></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-92142447494195630572014-01-03T15:59:00.001-05:002014-01-03T15:59:54.764-05:00List of free Programming Books<div dir="ltr">There are more books here than I can read.<div><br></div><div><a href="http://resrc.io/list/10/list-of-free-programming-books/">http://resrc.io/list/10/list-of-free-programming-books/</a><br></div></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-85301518583892597742014-01-02T12:45:00.001-05:002014-01-02T12:45:59.072-05:00Wired review of a treadmill deskI really want to try this:<span></span><div><br></div><div><a href="http://feedly.com/k/18Zkn88">http://feedly.com/k/18Zkn88</a><br></div><div><br></div><div>Pair programming would definitely not work unless they make tandem models. :)</div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-17909891038795072752013-12-31T08:34:00.000-05:002013-12-31T08:35:17.523-05:00Random thoughts on Domain ServicesI finished Chapter 7 on Domain Services of <a href="https://vaughnvernon.co/?page_id=168">Implementing Domain Driven Design</a>. In this chapter the author mentioned it was a good rule of thumb to not pass repositories into entities. We follow this practice at work as well. Someone recently challenged me on this practice, and I didn't have a great reason to give to them on why we chose to do this. I thought it had something to do with persistence ignorance, but I couldn't remember exactly why we instituted the practice. Unfortunately the author really doesn't get into the reason why you shouldn't do this either.
<p>
The author also recommended to not put a separate interface on your domain services unless you have know you are going to have to vary the logic of the service with different implementations for different customers. We also follow this practice, but I feel like it would be easier to mock the domain service when testing an application service if the domain service had a separate interface. The author doesn't explain how he tests his application services.
<p>
The author did call out that there shouldn't be any business logic in the application services. He didn't really get into how he defined business logic though. We frequently get into discussions at work about whether some code should be in the domain or just in the application layer. The discussion usually ends up at is this code business logic or not. I think if we have AC around it and we would want multiple UIs (desktop and mobile) to follow this behavior then it is probably business logic.James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-54612294384958673172013-12-12T15:53:00.001-05:002013-12-12T15:53:31.841-05:00Automating ExtJs 3 to ExtJs 4 code conversion<div dir="ltr">I was thinking one of these tools might help me write a script to automate code conversion between ExtJs 3 and ExtJs 4. I don't have time to try it right now but wanted to save these links in case that job ever lands on my plate.<div> <br></div><div><a href="http://jsshaper.org/">http://jsshaper.org/</a><br></div><div><a href="https://github.com/ajaxorg/treehugger">https://github.com/ajaxorg/treehugger</a><br></div><div><br></div></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-60746305850369548052013-12-04T11:51:00.001-05:002013-12-04T11:51:03.776-05:00Video about how youtube works<div dir="ltr"><div>These guys have a really good attitude about solving a really hard problem.</div><div><br></div><a href="http://feedly.com/e/mI7rXNrQ">http://feedly.com/e/mI7rXNrQ</a><br></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0tag:blogger.com,1999:blog-3827876209171644067.post-40726516141089331922013-12-04T09:13:00.001-05:002013-12-04T09:13:18.606-05:00Article about Google building support for Mobile Chrome Apps<div dir="ltr"><div>This could make writing apps that run everywhere easier.</div><br><a href="http://feedly.com/e/-kuNBX3M">http://feedly.com/e/-kuNBX3M</a><br></div> James Biglerhttp://www.blogger.com/profile/08626306693019609425noreply@blogger.com0