Friday, September 30, 2016

Using Html Entities rather than Icons

    This article is my opinion on the subject of html entities vs. png or icon files in a web application. If you have been watching bootstrap and seen the beta version of bootstrap 4 you might have seen some of the examples using entities. Initial I thought this was an improvement and in a lot of ways still do. But now I have given it some thought about the longer term of solution. I still think font-awesome is a much better choice to go because of the ability to modify the styles or simply create custom ones in a svg.  I know entities are nothing new but just wanted to write out why I would use them in some cases and not others.

Use case for Entities
    For one of my sites I actually used the up and down triangle entity. I think it’s a good fit for one the ui-grid and other javascript libraries that require some kind of indicator of sorting. In this situation it’s really a grey area of whether the icon should be an icon or entity because in this use I'm not going to style it all that much. As performance choice it’s also clear the entity is a better selection so I guess this is where I split on the decision whether to use entities or icons. So to sum up my thoughts in a javascript library I could see it being necessary to limit of css.

 ▲ ▲, ▼ ▼ or fa-sort-desc fa-sort-asc 
Use for icons
   Like I've stated I'm using font-awesome and in my opinion I think there are more scenarios that icons solve over entities. Now if only font-awesome was easier to modify in inkscape or a free tool then we're talking. You could do what you want with the icon files just as would with the sass files in font-awesome. Maybe font-awesome just needs a grunt/gulp package that looks at the sass files and adds/removes the svg related to css selector. Not that the icon files takes up a lot of space but it would make customizing it that much easier.

Wednesday, September 28, 2016

Dynamic Development to Static Deploy

   I believe this is an approach beneficial to any application for performance reason. If an application needs to be scalable but can remove the dynamic references there is a opportunity for improvement. With task runner or build process like gulp, grunt and mvc's bundle for example this is the same solution. What I'm point to is the things I want to create in javascript but don't necessarily need to be dynamic. For example Angular's template property with directives or component's and even routes. While I do like to use templateUrl in development for performances reason I want to include it in the statement as a template. If I'm trying to make the most of my code I need to inject directly
but for validation or organizational reasons I want to point it dynamically.
   This isn't a new problem in the computer science field but I think a lot of web developers will agree to injecting regardless if its development. It makes the code a little less manageable in my opinion but the performance is a higher priority. So to go back to these task runners or build processes we can change all that. This gets me to where I want to be in my development. So my code is dynamic for development but "static" or injected in this sense for deployment. I know there's probably a bad choice of words for describing this problem but its just how I've logical grouped it with similar situations where the output really is static and just pointing to a variable.
   I haven't found any grunt/gulp projects that convert the template/templateUrl properties. However I did find one that converts ng-includes. This helps out with my partial views but for now I'm looking to parse my javascript and looking for the templates to be injected.

  • grunt-nginclude
    • With $templateCache 
  • gulp watch-partials
var templateCache = require('gulp-angular-templatecache'),
    watch = require('gulp-watch');

gulp.task('generate', function () {
        .pipe(templateCache('templates.js', {module: 'YOURMODULENAME', standalone: false}))
 gulp.task('watch-partials', function () {'public/*/partials/*.html', ['generate']);

Top-Down Development

    If you ask me what my development style is like? I would have to describe it as a form of top-down view with a model view approach. I've been describing my approach to build web application this way for a few years. Every now and then I encountered a developers who will agree with this approach. I guess you can just take the definition from wiki page but really I have my own way of marketing it.
    "Throw everything away thing and get ready to start fresh. That's just how it is with every new javascript framework and I think it’s safe to say if it not middle-tier or backend code get ready to rebuild it. This is actually an awesome thing and you need to believe it because forcing development to the backend or middle tier every time something new comes along isn't realistic. Besides why not have the biggest impact on an application's lifecycle with the least amount of work!?"
    This is how I marketed my approach it probably could use some work for some developers follow or get excited about. Regardless if you agree with me I'm out to make everyone's job better. It's a javascript world. Love it or hate it but nothing is the right answer forever in a rapid development environment. Whether you're using react, angular or something else you can't ignore the possibility that your code could be better. Well some can, but I like to step around those type of developers and just push through.
   At the end of the day I do know it’s about results and results pay the bills. However mobility and new capability with your application sometimes takes priority for me. There's always going to be another feature you could have created or improved but what if it takes less time in a new framework.
  Currently I have a way to simplify this approach. I'm not going to go in depth because it’s easier to show and I'll probably work on example in the future but to understand it you can try it with any existing website. From a frontend perspective you can completely redesign any site in seconds.

The steps to take tackle any website project
  • Layout
  • What's the setup for the navigation? Dashboard or mobile like? Build index.html and pick your js libraries. 
  • Design
  • Colors, Shapes and size! Start creating css files.
  • UI/UX Flow
  • Learn the routes and where things connect. Starting creating js routes.
  • Endpoints
  • API and data coming or going. Start creating javascript models in typescript.

Data is a Black Box
    One of the things that has helps me is to think of data like a mystery box until I'm ready to write it out. I don't care where the data is located or what different types of content are listed in a given record. Instead I just want a sample of the fields and an outline of the data types so I can guess what the data might look. From there I might think about the upper or lower bounds for each data type if I need to test. Example a telephone number, I don't know if its international but I would include it in my tests or user interface for support.

As spend more time on a project my data types start to change and this is where the foundation of my projects starts to move a little but my frontend code is always ready handle the new structure change. Just in case I didn't like a redesign or solution to the UI first.  This is why I always recommend treating data like a box black.

Everything is a Prototype
   Chances are if you're updating an old site your manager will be worried things will break and use the excuse that there isn't enough time but keep rolling out with a new features while including new stuff you want in the mix. While working on this mixed version have a new version that is completely separate from the existing application so you can compare notes. I don't believe anything I do with frontend code to be set in stone and neither should you!

Final Notes
   If you read my article on "sandbox methodology" you might say this approach enables such a situation that I want to avoid. And I would agree but I think in a longer terms it is good for combating it. Give you and your team enough time to address the issues in your development approach. Development can be fast and be done right if everyone is on the same page. Which is way I strongly recommend using a Lean methodology to improve your team's collaboration.

Friday, September 23, 2016

My Orchard CMS Experience


This post is just to document my experiences with Orchard CMS and to list some of the resources that I used while developing a orchard module. I will go back through later and clean this post up but for now here is the code that I created with a previous employer.


Wednesday, September 14, 2016

The Sandbox Methodology

    "Sandbox Methodology" is a term I like to use to describe environments that have zero rules in place against the quick and the dirty practices when it comes to designing an application or implementing one. The term comes from of course sandbox and what most developers are used to with development practices. In a sandbox you have a place where you can experiment with all your work before it faces the harsh world of usability. However in reality, this environment is miss used and becomes a playground for project managers or basically anyone in management to see how far you are in the implementation. Or it’s used to build out requirements, "let the developer figure out what I want to be build playground". Long name, terrible results… You might be familiar with other methodologies but this is one you will definitely regret using.
    It could be said this approach is more of a waterfall methodology and employers will call it Agile. Chances are it’s a horrible mess and covered with crap that both developer and managers don’t know what it’s for.  A lot of people probably have different names but I’m calling it what it really is a sandbox. Nothing is stable and no idea is concrete. Which will lead up to my next article on Top-down development, and the whole reason why I become strong at front-end technology rather than middle-tier.
Developers how can produce results in this type of work environment come out on top but risk the weight of the project falling part if they don’t have enough experience with a particular company’s expectations.
   I think after six months at any company I can build any website if a limited number of questions. “Where this go does and what does this say”, I already know what a button needs to do and where the placement of objects need to be on the screen. So by the end of this six months I’ve already cut cost of time down by half and build pretty much anything a company needs in the UI but why do problems or bugs keep coming up? In my experience the biggest reason is collaboration or lack of it. Most developer are not strong at javascript or don’t rely on it. The other issue is a limit in scalability and technology. Sometimes you inherit an old project that management doesn’t want to move away from. Which leads to new features being hacked to work, because most code isn’t documented and self-aware of open source alternatives.

   So to sum up and make sense of what I’m trying to say. Sandbox methodology is a misuse of the developer’s skills and lack management understand. Or it’s really big problem in the industry for people in control of the project to grab ahold of the right people and all the right questions before setting out to build the project. This could be because of number of reasons.  A lack of conversation it to the developer, whatever the reason is one I know for sure the right skills in to be in the right position to make the necessary decisions for a project’s success.