You can listen to the podcast and read the show notes here.
Michael: Welcome back to the show. I'm here with Steve Neiland and he is senior developer at ‘Site Vision’ and he's joining us here from Florida; where it's probably hot and sunny and humid as it usually is in Florida at this time of the year.
Steve: It's only eighty degrees.
Michael: Only eighty degrees. All right well that'll get you ready for Washington D.C., the height of summer where you're going to be in a few weeks at sea 00:29 [inaudible]. And today's episode, Stephen and I are going to talk about going modular with FW1- frame work 1 using subsystems and he's going to talk about a 2.0 version of that. And we'll look at what framework 1 is for those you don't know and why you should be using a framework being factories and while there are exciting things to do with that. And also about subsystems and how you enable them and access them and whether you should be using them and if so how. And we'll also have a look at see if objective and maybe we’ll mention Lucy a little bit too. So welcome Stephen.
Steve: Thanks for having me.
Michael: You're welcome. Now I hear you have a slight accent where you're originally from a country in Europe?
Steve: Yes, I'm from County Cork Ireland originally.
Michael: Fabulous, sounds beautiful. So you gave up rainy, damp weather to have hot and sunny Floridian weather.
Steve: Yes and I'm not going back I like it warm.
Michael: Well, I can understand. I used to live in England and I found it a bit rainy and dark in the winter.
Steve: What part of England were you in?
Michael: I was in a town called Maidenhead Berkshire which was in the south, still is in the south as far as I know.
Steve: you hope
Michael: Yes, I hope.
Steve: It washed away you never know.
Michael: Yes, might have done. Well let's start for those folks who don't know what frame work 1 is. What exactly is FW 1?
Steve: Okay well, this is a question I've had to answer for a few people recently. So 02:10 [inaudible] is that frame work 1 you have to understand what is a framework. And basically, a framework is a convention of libraries that you use to organize your cohort and there's been many frame works over the years. The big one used to be fuse box. Now we have frame work, call box, C.F. wheels. I'm sure there are few others I'm not mentioning but frame work 1 and call box are the big names these days. And basically, it just helps multiple developers organizer calls in a consistent way and it gives you all different advantages depending which one you use. But the main cost is organize your calls consistently.
Michael: That sounds like a good thing to do and probably makes maintenance a lot easier on the code.
Steve: You would think. I've seen some abuses of frame works that would make you think they would be better off not using one. But in general if you've got a decent developer, they would take the advantage of a frame work.
Michael: And you know we did a survey the state of the 03:26 [inaudible] survey and the framework 1 and call box and still fuse box is still a popular framework out there. But one of the other ones is the homebrew framework where people come up with some way of organizing their files. Why would you recommend someone use something like framework 1 rather just coming up with some method themselves?
Steve: Well, I would recommend anyone use frame work 1 or call box or any of the other open source frameworks over their home brew for the simple reason that as you upgrade your engines from C.F. 8, C.F. 9, C.F. 10, 04:05 [inaudible] Lucy 4.5, Lucy 5 things will change. And it is much better to have someone else work out the bugs in a framework and you deal with your problem to the domain than having you to work on your framework and the problem domain is bugs. So [inaudible] are a lot of smart guys who build these frameworks like Sean Corfield is the guy behind framework 1. He's a lot smarter than me in many aspects. He knows framework inside and out. He worked originally on fuse box I believe before he created frame work 1.
Michael: he did?
Steve: Yeah, so I think of it as using someone else's framework is allows you to stand on the shoulder of giants.
Michael: That makes sense totally. So, having said we should be using a framework and there’s several of them out there, why use framework 1 over other frameworks?
Steve: Well, I'm not going to say that frame work 1 is the best framework or it's the worst framework. Like they all have different advantages. For me framework 1 is a very easy frame work to get into. Frame work 1 and call box do I'd say ninety percent of the same things is again call box gives you six hundred other things you could do that you might not necessarily need to. Frame work 1 is a very lean framework. It does one thing very well whereas call box can do everything very well if you know how to configure it or if you can reach the mountain of documentation that it is call box.
Michael: That makes sense. So it depends what kind of thing you're looking for. Do you want the framework to do a lot of things for you or would you rather it stays out of your way and just does one thing good?
Steve: Yeah and that would be the same way why I would use a taffy for building an A.P.I. Taffy being at a rest A.P.I. framework because it does one thing very well. You don't need to learn all the things it need to do.
Michael: Makes sense cool. So, we're convinced we should be using framework 1 but what are these new subsystems that are in framework 1?
Steve: Well actually, subsystems are not new to framework 1. They were in the 1.0 build of framework 1. Sean didn't add them to the system. They were actually added by another person who I would like to give credit to and if I can think of his name. I have it on my notes. Ryan 07:11 [Cogswell]
Michael: Oh okay, Ryan alright.
Steve: Yeah, he had it, frame work 1 back in 2009. What they are basically is… frame work 1 by its nature is a very flat structure. You have… If the hierarchy is you have sections and in each section you have items. So you would have state user section and them an item would be user.edit or user.save or user.delete which is fine for most applications. But sometimes you will want a nest, an extra nesting so you might say have a calendar. List and counter list.edit counter list.save. So it gives you that third level where you can group your 08:02 [inaudible] logically.
What's different about subsystems 2.0 is how to configure it. Like the old subsystems to enable them, you had to jump through a few hoops which it was always an issue for me to add in an environment variable, move around all your existing code, create another set of folders for some other code. At the end of the day, it was a bit of a pain and it wasn't very well explained what the benefits were. So most people never actually used subsystems. Were stop systems 2.0, add them to your application you create a directory called subsystems and then you just drop in a particular subsystems code and it's just done.
Michael: So it's the kind of module of code. Maybe an hour goes to Word Press plugin or…
Steve: I wouldn't say a plugin because subsystems are not plugins but they are modules. So how I would describe is a subsystem is a cut down version of a normal frame work 1 application. So it had the same convention, same for structures. But it's not something you can just drop hints. You can drop in your security system for creating your users and authentification which is probably the most common use of a subsystem when doing much more design.
Michael: And do subsystems have some U.I. elements as well or they purely are functional?
Steve: No, they're completely… Like I said there are a cut down version of a standard frame work 1 application. So you have your model, subsystem has its own model directory, it has its own controllers, has its own view files, has it’s own layouts, it's own C.S.S. And that's all coded. You can just drop into one or more applications 10:04 [inaudible] the box.
Michael: And it sounds somewhat similar to call box modules.
Steve: It is very similar to call box modules. In fact it's a lot of the conventions and concepts are the same. It's just the difference between the implementations.
Michael: So you mentioned some of the new features in the two point zero versions. Tell us about some of those. For example, how do you enable subsystems now?
Steve: Well, I’ll say to enable subsystems in 2.0, you create a directory in your main application called subsystems and then you drop in your subsystem into it and it just works.
Michael: That sounds too easy.
Steve: Well it sounds too easy but it's just that easy. Like once you've written your subsystem to work correctly, you can drop in to any frame work 1 application that's version 3.5 or above.
Michael: Wow! So in the version 1.0, it was more complicated I believe.
Steve: Yeah, in the version 1, you actually had to move all your existing framework 1 code into a sub-directory called Whole and then all your layouts into a directory called Common and then you had to create another directory for your subsystem and drop your code into that. Then you had to go change some environment variables and do some wiring up. It really did not go along with the frame work 1 methodology often convention over configuration. It actually made you do a lot of configuration which I tribute a lot to the fact it was not something Sean built into it from day one.
Michael: Well that sounds much better. So once you've dropped your subsystem into your app, how do you use it I mean?
Steve: Okay so basically to access a subsystem, if you look at the url structure of a normal frame work 1 application, the url 12:21 [inaudible] will read action equals section.item. So [inaudible] for that would be users.edit To access a subsystem, url string changes to be action equals subsystem colon section.item So, that will be counter colon day.edit or counter colon.event.add. So and that's literally it.
Michael: That sounds really easy for you; send, edit makes the code easy to read too.
Steve: Yeah and it makes navigation really simple because the helper functions that builds links in the application; it's called Build Your Url. It does all the thinking for you. Like it's all relative addressing so, you can have buildurlitem.edit. And if you drop that subsystem into your application 1 and you’ve named your subsystem events calendar, it knows that it's in events calender colonuser.edit whereas it can be in pick up calender in a totally different application and it does all the auto wiring itself.
Michael: Cool so, what else is new in 2.0 subsystems?
Steve: Most of what else is new in subsystems is the conventions and a lot of back and cold to make things just work automatically. For examples, in been factories are much more much easier to use. Before, you still can use different bean factories but since version 3 14:18 [inaudible] DI 1 dependency injection framework that Sean built has been bundled with frame work 1 and it just altered wires straight into subsystems as well.
Michael: And for those people listening who don't know what a bean factory is, what is a bean factory?
Steve: Oh okay so, without getting too technical, in a bean factory, you have your model which is your services, your gateways you're bean like you might have a user bean which would describe a user, a day bean which might describe a particular day in your calendar. And without a bean factory, you have to do a lot of manual worrying up to say when you're in their calendar create a day, creating an array or a day, create a CF objects for this path and then that has a dependency on the Gateway which does the careering. And what DI 1 does and 15:25 [inaudible] are frameworks to as you just define a property at the top of your C.F.C. file and I must say user’s gateway or user service. And DI 1 will read all your controllers, all your service directories or gates and say oh, you need these other beans so, here's a reference to you can just use it. It takes a lot of day manual for it.
Michael: And how does that relate to dependency injection?
Steve: Well, that is basically what dependency injection is. It reads all your C.S.Cs and sees that all you need a reference to this other object. So here's your reference instead of you having to manually inject it.
Michael: Got it. So you don't need to use a separate dependency injection framework if you're doing that.
Steve: No because DI 1 is part of frame work 1 now. But if you want, you can go ahead and use call box’s version which I believe is called… I actually don't remember what the call box’s version is. But I know it's a standalone version that you can load in as well or if you are fairly quickly masochistic you can just write your own dependency injection framework.
Michael: I think we have the masochistic listeners behind when we said we're going to use no consoles framework instead of coding our own. So, I hope you do.
Steve: So yeah.
Michael: Wire box was the thing.
Steve: Wire box, that’s the one and I actually used wire box with frame work 1 back in the 2.0 days before DI 1 became bundled and I will say I prefer the DI 1 to wire box. But that's my own preference.
Michael: So having got all this stuff working which is now very easy to do, why should folks listening be using subsystems?
Steve: Well, it all depends on the kind of shop you are. If you are building a single application that you support and that's it, then subsystems they're going to give you minimal benefit. They're going to give you that extra bit of organizing your code and that's about it. If on the other hand you're like site vision where we have multiple similar applications that are in different domains and you want to share code between them, that’s when you get the benefits.
For example, we have… I’ll take trade samples. We have an application that is used for trash pick-ups for a county. So, there we have another application as he is by veterinarians and then we have another application that's used by emergency services. They're all very different applications but they all have one thing in common which is security. Like they all have user’s accounts, permissions, groups. So, when we create those applications the old way you would do it is you would copy across your security code for one application to the next one and modify it as needed for that application. And then you would build another application for someone else, copy across that security application model, modify the security code for there. But now you've got three different versions of the same security code and if you have a bug in the first version you not have to fix it in three separate places. Whereas with us a security sub system, that's its own reports its own source code repo and if you find a bug in it, you fix it in one place and deploy two to three different applications and they all get that fixed straight away.
Michael: So, you're dropping a copy of the code into the subsystem directory in all three places. You're maintaining that subsystem and get all some other place to keep it centralized.
Steve: Yeah, separate to your application.
Michael: Got it. So, sounds like a no brainer to use subsystems. Are there any times when you shouldn't be using them?
Steve: There are a few cases. Like if you really need to define what is unique to your application as opposed to what is shareable to your application like security and also indication that is going to be the same in every application. But like a calendar is going to be pretty much the same between every application. But then, trash pick-ups like the definition of a trash pickup is going to be different from the definition of an appointment for your door to get fixed. So, those parts of where they go in to your core application versus a subsystem.
Michael: And does framework 1 do auto wiring of these the subsystems or?
Steve: Yes, everything is auto wired.
Michael: So tell folks what that means 21:09 [inaudible]
Steve: Well basically, what the auto wiring does is you drop in your security subsystem and your application. Your subsystem has its own model risk beings and services and controllers and they all have dependencies on each other. And frame work 1 goes along says oh, here's a new subsystem 21:31 [inaudible] controllers. I'm going to wire it in so when someone hits this url, they find it, it out find services wire it up to a controller. So, it all will just run. So it's a zero… what minimal configuration. There is some configuration with subsystems but that is depend on what your requirements are.
For example, taking a security system. So on one of your applications, we might say users need to change their password every ninety days. Another one might say we need to change the password every two months or every one day or every five log-ins. So we have feature flags that we set up in the receptive force of the subsystem and then your application, the C.F.C. we will provide overwrites. So Application A we say, days to reset the password equals ninety. The second application we say, days to reset equals zero. I never reset. So, it's the same code but different behaviors depending on those features flags.
Michael: That makes sense. If you're reusing code you need to do something like that. So, tweak how it behaves. So, I am going to link in the show notes there's a nice piece of documentation using subsystems and framework 1 that’s on the frame work 1 documentation set. And if folks are interested in learning more about subsystems I think that's a good place to start. Are there any other resources you can recommend for subsystems?
Steve: I've done a couple previous presentations for this one so, they are going to be available on my get help account once I update this version and there will be actual sample applications. They're implementing to different concepts because we've only scratched the surface a lot subsystems can do.
Michael: Okay, that sounds great. So we'll put a link in that as well in the show notes as well. So anything else you want to share about subsystems before we move to a separate topic?
Steve: No, I think we've covered enough to get people interested. If they want to learn more they can come to my presentation 23:58 [inaudible] objective.
Michael: Fabulous so, let's just change topic. Why are you proud to use cold fusion?
Steve: I produce cold fusion because funny as well, the original scripting languages for web application as old as P.H.P. which I don't think people recognize and it just makes things easy. Like 24:25 [inaudible] will say all your array is beginner one instead of their own. But I think it was a language that was built for real people as opposed to be are scientists and I believe they’ve kept that goal, 24:42 [inaudible] Dorothy and Lucy.
Michael: Yeah, definitely easy to get started in though that doesn't mean it can't be powerful if you need to take it in a more computer sciencey direction.
Steve: Exactly and which is something that we're doing in a side vision. We're taking it beyond the descripty type application to real high stakes usage because we work with emergency departments and hospitals. And so it's a language that we feel comfortable using in those environments.
Michael: Fabulous so, some people have said cold fusion is dying but what would it take to make cold fusion more alive this year?
Steve: For me I think cold fusion from a technical point of view is not dying. What I believe is and has always been an issue in my opinion with CFO 25:43 [inaudible] if it's really not just call fusion it's Lucy is P.R. Adobe has never really marketed cold fusion to the masses and they've always been very fortune five hundred, big corporation type clients they're going after which doesn't get into schools and the mainstream. And Lucy has done a lot and for 26:13 [inaudible] them to make it available to people who don't have big corporate checkbooks. But marketing has always been a weak point in my opinion and I do know that Lucy had been doing a bit with Mark 26:28 [inaudible] travelling around, pitching it to… I want to say universities although, I could be wrong. But he's been actively marketing it. But I believe it needs more in the marketing department because the language is stable. It's doesn't have any quarters. It's got a good support base it just needs visibility.
Michael: That makes sense. So, what are you looking forward to a CF objective this year?
Steve: Well, I'm looking forward to seeing Adobe back at CF objectives. They want the last one was the [inaudible] and I believe the sponsoring this yes what I think does a very positive thing for the community. I'm also looking forward to hang out with the Lucy guys and seeing what new awesome things they've got in store because I know they’ve got good things in store always work on something for. They are tossed it or chess until their sessions.
Michael: Brights and I know 27:42 [Gert's Talk] has a couple of talks this year. So, should be some good stuff there. I think one of the things is speeding up the loading time.
Steve: Hint, Hint! It is Lucy.
Michael: There you go. So, I know last year 28:00 [Dev] objective had a few issues. What would it take to make CF objective to be more alive?
Steve: Well, that's a very tough question to answer because I don't believe that CF objective or Dev objective or whatever its name is is doing anything wrong or that or is anything more they could be doing to promote a conference. Maybe they can be doing bit more P.R. at all the conferences. I don't know. I really think CF objective is a reflection of the public view of 28:43 [inaudible]. And I believe that Adobe was their marketing of C.F. so much has taken away some of the big names who have been going to CF objection. I think they are going to go to CF so much instead.
Lucy, I think they need to step up their game marketing wise and more active with the blog posts and doing to Rob we're awesomeness. I think as you promote language, as a language because popular, it will feed into CF objective in terms of attendance.
Michael: That makes sense to me. So, you mentioned Lucy there. What would it take to have Lucy be more lives this year?
Steve: Oh, more alive. I’ve been somewhat vocal on some of the things that Lucy has not been doing very well in the past. For example, documentation has always been a weak point of Lucy because no one likes writing documentation. But I think when you have an open source of language, the documentation is at least fifty percent of the products and they’ve neglected that open until very recently. So, I would really like to see them continue to expand on the documentation and make it much more comprehensive and much easier to get into. I’ll say the marketing. There are also some technical issues with Lucy. I've noticed a couple of posts by the likes of Adam Cameron and others who've done real compactor testing of CF I'm out against other languages. And if I just wanted a bar comparing moment J.S. verses C.F. 30:42 [inaudible]. And it was quite disappointing to see how many times both the C.F…. engines failed versus a moment. Yes, I'd like to see that be addressed like a big push to say what the other language is doing better than us and how can we get up there.
Michael: Cool so, if folks wanted to find you online, what's the best ways to do that?
Steve: Ted speak with me normally Twitter is the best way to get me. I tweeted S. Neiland. Otherwise, I have my website Neiland.net. I haven't been a very prolific blogger the past year. I’ve been working on other things and in the last months or two, I may have broken my blog in terms of the publish feature. 31:36 [laughing]
Michael: All right, do you have some attraction to dinosaurs? I see more Godzilla on your a Twitter profile.
Steve: That came from my previous jobs where I was upgrading an application from fuse box store and I kept burning cross code. I made me go face found. So and one day I came across 32:07 [inaudible] I was like not just code is so bad even God said it would fit and I found it. So that's what it means.
Michael: That explains that. I had always wondered about that. Well, I really appreciate you joining us on the C.F.O. live podcast Stephen.
Steve: Thanks for having me. It's been fun.
Michael: great.
