Hello, World! - amazing post, source link at bottom

February 26, 2015

When a programmer picks up a new language it is customary to write the timeless Hello Worldapplication to ease your way into a daunting codebase with an overly-simplistic view of its syntax.  I’ve personally done this at least 20 times throughout the last 13 years of my life starting in college, and up to about two years ago as I was diving into ruby.  It’s an interesting concept to me, really.  You take an incredibly advanced and complex programming language, and dumb it down to the absolute bare essentials in order to embark on the journey of learning a new system.  Today, I begin a journey in which I look at the concept of “Hello World” a little bit differently.

I started my life as a programmer at a fairly late age in comparison to most others.  Though, I had always been fascinated by computers, I didn’t really get into things until my second year in college after taking an introductory computer science class.  Writing that first Hello World program in 8-bit binary took about 8 hours to complete with a lab partner, and spanned about 3 pages of 8.5″ x 11″ printer paper.  I was so undeniably fascinated by what we had accomplished that I ended up changing my major the very next day.  After 4 more years of college I decided to call it quits with s0-called higher education, and continued learning to code on my own.  As a man who was raised by a fairly “normal” family and a fairly “normal” society, without even thinking twice about it I started to look for jobs.  After about a month of searching I was hired by a company who managed data for insurance agents.  This was it!  This is where my real life actually begins!  Little did I know it was really the beginning of the end of my life as a programmer.

This particular job was an incredibly bad one.  A super conservative environment where all of the developers (code monkeys to the fullest) were shoved in a fluorescent-lit room with no windows to hack away at bugs directly in production environments.  It only took about a year and a half for it to fully suck my soul away, at which time I ultimately quit.  Over the next couple years I began working as a chef, and as a bartender to make my living and I was fairly happy with that lifestyle.  After two years of slinging craft beer, preparing braised short ribs, and drinking with friends until the wee hours of the night my girlfriend at the time gave me the news that we were having a child together.

This news instantly put me into dad-mode, and I knew that it was time to go back to the “real world” to get a job with a good salary and benefits.  This time, however, I lucked out in a huge way (or so I thought).  I ended up with one of the most amazing companies a person could ask to work for, and they offered the ideal package.  A great salary, great benefits, trips to Vegas and New York City, a great group of people, a host of fantastic client names, beer and whisky in the office, and the occasional happy hour event outside of work.  They utilized modern web frameworks, version control systems, cloud-based service providers, automation tools, and I learned more in the next three years than I could have learned in a lifetime with most other companies.  They treated me incredibly well as an employee, and as an actual human being.

Today, however, I sit here writing this post as a 32-year-old man with a head of gray hair, a mind that cannot stop thinking a million miles a minute about a million different things, and eyes that have only been open to the digital world.  I am burnt out on writing code.  I am burnt out on configuration.  I am burnt out on automating monotonous tasks.  I am burnt out on completing tickets.  I am burnt out on completing tickets that undo what those other tickets accomplished.  I am burnt out on debugging third-party advertising code.  I am burnt out on having 16 terminal tabs open.  I am burnt out on contributing to the “connected” culture.  I am burnt out on having a “40 hour” work week that actually occupies the majority of my mental time.  I am burnt out on sitting at a desk.  This state of being burnt out has invaded so much of my out-of-work life that I have decided to take my Life back.

Actually, I lied.  Today, I stand here with 2 days left at my current job, and a new fire inside of me that I can’t hold back.  Next week I embark on an adventure that consists of working on a local farm, and building a tiny house on wheels.  An adventure that puts my bony, cramped fingers back into the earth where they belong.  An adventure that allows me to build, engineer, and grow tangible creations that I can be proud of.  An adventure that will release me from what I consider to be the life-long imprisonment of a mortgage or rent payment.  A journey that allows more time for me to be an active participant in raising my children into good men.  A journey with a larger purpose.  A journey that will feed me in ways money cannot. A journey that will breed true Life.

Today, I write these words without fear of errors or exceptions…

Hello, World!

source: http://hello-world.io/hello-world/

grails auto refresh a div with jquery

I guess the toughest dead end i had so far - i needed to refresh only a part of a page, one div, every 10 seconds, for example. I had completely no idea how to solve it. After some time and no responses on SO i thought that i probably needed to create a separate view and point the div to this view with jquery, something like that. 

The solution turned out to be almost like i thought.

I've solved this with help of joshm76 from #grails on freenode.

There are several steps for this solution:

1. i need a template with the div contents i need to update
2. i need a controller that with a model passes needed values to the template
3. i need to include this inside the div i want to update with a 
4. with jquery i update the div contents

1) Template is a .gsp file with _ before the name, like _myTemplate.gsp. Put it in the view folder of the controller you will be using.

2)

    def action(){
    def var
    //some logic to populate the variable

    Map model = [myVar: var]
    render(template: '_myTemplate', model: model)
}

in the template the variable can be accessed with ${myVar}

3) inside the div you need to update, put the <g:include> instead of the content you had there before (now the content is in the template)

<g:include controller='controller' action='action' />

4) the jquery part (fetches the template every 5 seconds):

    $(document).ready(
            function() {
                setInterval(function() { 
                $('#divId').load('/app/controller/action');
                }, 5000);
            });

you can also use the $.get() function, the result seems to be identical

Grails debugging

Debugging with grails is extremely easy.

1) Run your app with grails --debug-fork run-app
2) Wait for it to accept connections
3) Remote debug on localhost and port 5005

grails gsp form vs g:form

I had this problem recently. I have several forms with submit buttons, that call different controllers and actions. And i used simple <form> tags. The submit buttons were calling completely different controller that was specified in the <form controller=''>. Well, turns out that to user controller/action parameters i have to use the grails <g:form> tag. Almost broke my brain on this.

Queit

My current pet project is Queit, a web service for creating queues. I had to begin from scratch, because my approach before i read a few books on grails was completely wrong. I started on around 22 January and now the main functional is working. Just some fixes there and here, a decent design and probably ready to launch.

And then like BOOM out of nowhere - my friend just launched another startup. An anonymous messenger. He has a lot of resources, but made this mobile app completely on his own. And i am sure that he will reach his milestone - 200 000 users.

I am insanely motivated!

Elon Musk never gives up.

After 3rd unsuccessful launch of his rocket Elon faced a decision: quit, or invest everything he had left in the fourth attempt.

Grails bad practice #1: storing domain objects in session variable

I've learnt that storing domain objects in a session variable is a bad practice. I had to refactor some code, and now everything works correctly. Where were problems when i needed to access some domain properties inside a gsp, but those were solved by passing the needed parameters, not the whole domain classes.

I had a controller and a corresponding gsp code block:

def user = session?.user
    def queue = Queue.findById(params.queueId)

    if(queue){
        user.removeFromQueues(queue)
        queue.delete(flush:true)

        flash.message = "deleted queue with id: ${queue.id}"
        redirect(controller:'queue', action:'index')
    }

<g:each in="${session?.user?.queues}">
        <div id="queue">
            ${it.name} id:${it.id}
                <div id='queueButtons'>
                    <g:hiddenField name="queueId" value="${it.id}" /> 
                    <g:link controller='queue' action='delete' params="[queueId: "${it.id}"]">X</g:link>
                </div>
        </div>
    </g:each>

Now i dont save user in session, i save userId in session, and when needed fetch the user in controllers. On gsp where i needed the user domain to get queues, i passed session.queues that was set in a controller after a user fetch session.queues = user.queues.

racetrack and collab-doto public repositories

Hi!

Sharing my completed racetrack and collab-todo apps from "Beginning Grails, Groovy and Griffon" and "Getting started with Grails"

racetrack @ BitBucket

collab-todo @ BitBucket

Finally back to work!

My exams are over, and i also finished two books on Grails and built apps from those books. Those books were: "Beginning Grails, Groovy and Griffon" with the "collab-todo" app and "Getting started with Grails, second edition" with the "racetrack" app.

Now i will have some time to dedicate to my projects.

I am purposeful and motivated. I do not wish to waste time anymore.

Beginning Grails, Groovy and Griffon security filter problem.

When i implemented a security filter in my collab-todo app, the only page the filters allowed an unregistered user to view had no styles. Turns out that the assets path was also blocked by the filter.

Thanks to Joshua Moore for answering my question.

The problem is that:

because in recent versions of Grails (2.3+) assets are served up by the asset pipeline plugin from the /assets/**URL.

So the filter should be

securityFilters(controller:'*', action:'*', uriExclude: '/assets/**'){}

instead of just

securityFilters(controller:'*', action:'*'){}