Fat controller or Fat model???
When coding up an app using the MVC model, how much of logic do you actually code up in the controller?
The controller’s job in an MVC setup is to pick up action requests from the user acting on the View, pass them to the model for data manipulation and pull out the new view to show to the user.
Now, the question in my mind is: How much of logic do you actually throw into the controller?
- Is the controller supposed to have ONLY routing logic? * Is it allowed to know anything at all about the view and the model it is mediating?
- Is the controller permitted to to have any session logic to quickly handle logged in / logged out users?
- Is pushing any and all processing to the model the right approach?
Just a few questions that I have in mind…
Draft - Go Write
TL;DR - I introduce a new service called Draft by Nathan Kontny that lets you write, edit and version content collaboratively.
I love writing. Not many that know me know that I write a lot!
I Freelance as a content writer. Wearing this hat, I’ve always been on the hunt for a tool that will let me write at my pace while someone else who the content is intended for can take a look and suggest edits.
I use a Mac as my primary writing tool and don’t have the kind of cash to throw at Microsoft Office. So DOCX files are out of the question. Open office and Google Docs just dont cut it for me!
So, for me, writing content has been about putting a text file across, getting / suggesting the edits, finding them and merging them into my master and rinse and repeat.
I know! Cumbersome! #fail and all that!
Enter Draft, a wonderfully simple tool by Nathan Kontny solves this particular problem.
Sign up, create a new document and get writing. Simple!
You can write in Markdown - by far my favorite means of writing content or you can create pure html too.
Once the content is ready to be shared, draft creates a share-able URL that you send across to the other person for editing.
Whatever the second party edits is held as a separate version and draft gives you an email alert once they’re done so you can merge changes back into your document.
This ONE feature is something every person wearing the writer’s hat will need!
The other feature that I love is the ability to directly publish your content to blogs - draft currently supports tumblr and wordpress.
A yet another important addition to draft’s offerings is the ability to send your document across to a professional proof-reader content writer and get the document edited for a cost. Writers looking to gain some ground and wanting professional assistance for their documents have it covered here.
I love this tool. For those that are writing blogs or are curating some high class content with a peer group, draft fills a very important void very easily.
On Writing E-Mails
Emails are mainstay communication tools today! In this post, I talk about some tips to help communicate effectively via E-Mail…
Important tips to keep in mind when dealing with e-mail:
-
Hi Dear is not the right start to an official email.
-
Reply-All is evil! Every time. Do bear in mind that internet / network bandwidth is a cost you inherently bear out of your bonus!
-
Write small, complete sentences. It helps get your idea across. It helps relieve the reader of any confusion while interpreting your message.
one sentence spanning a full paragraph with absolutely no punctuation chock full of sepllnig misatekes and everything from lorem ipsum all the way to incomprehensible content again chock full of non readable grammer is cannot able to help anyone reading your precious mail
-
Every bloody editor that you use to compose emails can spell-check. Use it. If you’re using mail from the unix command-line, please close this browser window! I bow to thee!
-
Read! Re-read! Re-read the Re-read email! Ensure you’re actually conveying the message you intend to. Long emails tend to gobble up your message in all that noise! Point #3 helps solve that problem!
-
DO NOT CHANGE THE SUBJECT LINE. Start a new thread if you want to discuss something else!
-
While on point #6, focus on the topic being discussed. A Reply All asking about lunch is not acceptable on a thread discussing why a bug cannot be reproduced on the developer box.
-
Learn to take conversations offline. Email should be used to send and receive critical communication and thats that. Using e-mail as a chat application is pure stupidity!
-
Don’t use slang. Don’t use txtspk. Don’t go LOLCAT style with Y U NO REPLY TO MY MAIL if the context is official!
-
Last but not the least, ensure that your email is being sent to the intended recipient only or be ready to be facepalm-ed or worse, face corporate action!
Let me know if you’ve got more to add to this list… Happy e-mailing!
Represent your brand
When you talk to your customer, you’re representing the brand that the customer pays to use.
When the customer walks into your brick and mortar establishment, the last thing you should be giving him is a blame on another branch of your brand for having screwed up his experience.
You’re doing no good to the customer, doing no good to your brand and you’re effectively wasting his time and spoiling your reputation.
How about you quickly figure out how to get things going in the right direction?
Without blaming your counterparts…
Without blaming the customer for a sorry start to a bright and sunny Monday morning…
Without blaming the hot, scorching Chennai Sun…
Dear Axis bank, I love you folks and probably still love the way you get things done for me. I think I’ll let this ONE bad experience pass!
Everyone makes mistakes! The only problem people have is with collectively owning up a mistake and working towards fixing it!
A handy Unix shell tip
As a configuration management and release engineer, the vast entirety of my work is on *nix - Red Hat primarily and the odd Solaris installation.
While working on the command line with that black window and white text is bliss, I’m growing ever more conscious of the way I work - working smart.
Here’s a tip that I picked up recently and it has definitely improved my speed at one particularly mundane task - creating folder structures.
Assume the following folder structure that needs to be created:
folderA
|
--------folderB
|
--------folderB1
--------folderC
|
--------folderC1
The regular scenario would have you going:
shell$ mkdir folderA
shell$ cd folderA
folderA$ mkdir folderB
folderA$ cd folderB
folderB$ mkdir folderB1
folderB$ cd ..
folderA$ mkdir folderC
folderA$ cd folderC
folderC$ mkdir folderC1
Grossly inefficient.
With UNIX, there’s always a better way at this -
use the -p (—parents) parameter with the mkdir command and you’re done in a split second.
Like so:
mkdir -p folderA/{folderB/folderB1,folderC/folderC1}
The -p parameter creates parent folder structures as it sees them and ignores if they already exist.
The curly braces expand the list of comma separated values as individual parameters for the mkdir command. A point to note here is tt include a space between the comma and the next word.
Pretty useful tip to create destination folder tree structures via a shell script. mkdir should be universally supported on all distributions that conform to the UNIX specification - that means most of them in today’s time.
