Showing posts with label Geekism. Show all posts
Showing posts with label Geekism. Show all posts

Thursday 7 February 2019

Python progression path - From apprentice to guru


I thought the process of Python mastery went something like:
  1. Discover list comprehensions
  2. Discover generators
  3. Incorporate map, reduce, filter, iter, range, xrange often into your code
  4. Discover Decorators
  5. Write recursive functions, a lot
  6. Discover itertools and functools
  7. Read Real World Haskell (read free online)
  8. Rewrite all your old Python code with tons of higher order functions, recursion, and whatnot.
  9. Annoy your cubicle mates every time they present you with a Python class. Claim it could be "better" implemented as a dictionary plus some functions. Embrace functional programming.
  10. Rediscover the Strategy pattern and then all those things from imperative code you tried so hard to forget after Haskell.
  11. Find a balance.

https://stackoverflow.com/a/2576240/878451

Tuesday 3 April 2018

Why Learning to Code is So Damn Hard



From: http://www.vikingcodeschool.com/posts/why-learning-to-code-is-so-damn-hard






Why Learning to Code is So Damn Hard




What every beginner absolutely needs to know about the journey ahead


Erik Trautman wrote this on Feb 4, 2015 | 170 Comments




Quincy Larson was just a "guy in a suit in an office" and decided he wanted to learn how to code. So he asked around. He started by picking up a bit of Ruby then found himself skimming through other languages like Scala, Clojure and Go. He learned Emacs then Vim and even the Dvorak keyboard layout. He picked up Linux, dabbled in Lisp and coded in Python while living on the command line for more than half a year.


Like a leaf in a tornado, the advice Quincy received jerked him first one way and then another and then another until he'd finally taken "every online course program imaginable". By the end of it all, despite having ultimately landed a software development job, Quincy:


... was convinced that the seemingly normal programmers I ran into were actually sociopaths who had experienced, then repressed, the trauma of learning to code.


Ouch. Does that sound familiar?
Phase I: The Hand-Holding Honeymoon


It's really hard to blame anyone for coming into the programming industry with outrageous expectations.


On the one hand, you've heard rumors of how difficult programming is since you were young, like old wives tales meant to scare children into studying social sciences instead.


On the other, the "Learn to Code" movement has done a fantastic job of breaking down barriers and showing people that code is actually quite harmless. Tools like Codecademy and Treehouseand Code School reach out with the gentlest of touches to assure you that you too (nay, anyone!) can not just learn to code but become a full-fledged developer as well.


Suddenly the problem isn't fear, it's an overabundance of hopes and high expectations.


And, for the most part, these introductory tools do a great job of guiding you like a child in a crosswalk past the big scary variables and conditional statements and through the early phases of programming syntax. As you conquer one after another of their gamified challenges, your confidence rises. Maybe you can do this after all! How hard can it be? You're basically a developer already!




The Hand-Holding Honeymoon





Here's the problem -- you're in what I like to call the "Hand Holding Honeymoon" phase. Though you may feel like the end is around the corner, you're only a fraction of the way there. This is just the beginning...
Charting The Path Ahead


Before we dive into Phase II, let's look at the bigger picture.


In this post, I'll walk you through the four phases of the typical journey into coding and what you'll need to do to survive each of them. You'll also see how two key factors -- the density of resources and scope of required knowledge -- define this journey.


The trek towards job-readiness can be plotted in terms of how your confidence level changes as your capability increases:




The Learn-to-Code Journey -- Click to Enlarge





This is a relevant relationship because your confidence is highly correlated with your happiness and because the point where your confidence and capabilities match is the best proxy I have for the sweet spot when you're officially "job ready".


We'll look into the unique challenges of the remaining 3 phases in a moment, but this is what each of them essentially involves:
The Hand Holding Honeymoon is the joy-filled romp through highly polished resources teaching you things that seem tricky but are totally do-able with their intensive support. You will primarily learn basic syntax but feel great about your accomplishments.
The Cliff of Confusion is the painful realization that it's a lot harder when the hand-holding ends and it feels like you can't actually do anything on your own yet. Your primary challenges are constant debugging and not quite knowing how to ask the right questions as you fight your way towards any kind of momentum.
The Desert of Despair is the long and lonely journey through a pathless landscape where every new direction seems correct but you're frequently going in circles and you're starving for the resources to get you through it. Beware the "Mirages of Mania", like sirens of the desert, which will lead you astray.
The Upswing of Awesome is when you've finally found a path through the desert and pulled together an understanding of how to build applications. But your code is still siloed and brittle like a house of cards. You gain confidence because your sites appear to run, you've mastered a few useful patterns, and your friends think your interfaces are cool but you're terrified to look under the hood and you ultimately don't know how to get to "production ready" code. How do you bridge the gap to a real job?


I've interviewed hundreds of aspiring developers over the past several years and heard echoes of the same story again and again. My goal for this post is that you approach the learner's journey with both eyes open and enough of a plan that you can avoid the common pitfalls of those who have come before you.


Let's get back into Phase II...
Phase II: The Cliff of Confusion


So, you're in Phase I -- the "Hand-Holding Honeymoon" -- checking off badges and completing coding challenges while your confidence and capabilities grow. This isn't so bad... what's all the fuss about? You've arrived at the "Peak of Irrational Exuberance"...


Be careful! You’re about to overstep a precipice that’s broken many strong aspiring learners and relegated them to the “coding is too hard” camp. The precise moment this leap occurs is the first time you sit down at your keyboard, open up your text editor, and try to build a project from scratch without any of the fancy in-browser editors, scaffolded code or helpful hints.


Crap.


You might stretch this out a bit by following tutorials, but no one has ever reached the skies without leaving the ground, and, at some point, you're going to have to create magic from a blank text file. You've just entered the second phase of learning, where confidence comes crashing down to earth -- the "Cliff of Confusion":




The Cliff of Confusion





So you build. You fight and scratch your way to a barely-functional solution but there's something missing. You're at a war with bugs that makes Starship Troopers look benign. It feels like each victory was gained only by a stroke of lucky Googling and your confidence that you can ever figure this stuff out plummets.




Buuuuuuuuuuuuuuuuuuuuug!!!





This is a particularly frustrating phase to see as an educator and to all participants in our industry. Programming may not be perfect for everyone, but we want you to make progress because sometimes the unlikeliest of stories become the grandest successes.


When the hand-holding ends and students are pushed off the cliff and told to fly, too many potentially awesome people are spiraling onto the rocks of frustration without learning how to flap their wings.


The scary part is that you haven't even gotten to the meaty stuff yet. This second phase, the Cliff of Confusion, is still very early. Once you've finally squashed enough bugs to end the eighth plague of Egypt and actually finished a couple of projects -- thus marking the end of Phase II -- you're still just getting started.


For those who are truly ready to make a career out of this, surviving the Cliff of Confusion is often the point where you decide to go all-in with your new life. But too many are left behind. And, unfortunately, you're just about to enter the "Desert of Despair".
The Two Key Factors at Play


So what really marks the difference between one phase and the next? Why was Phase II (the Cliff of Confusion) so awful compared to Phase I (the Hand-Holding Honeymoon)? Understanding this will help you realize that it's not your fault at all if your journey looks like what we've just described.


Basically, there are two key forces at work in every phase -- Resource Density and Scope of Knowledge. Let's see what these are before exploring how they define Phase III.
Factor 1: Resource Density


As I said above, when you first start out, it feels like there are a million resources out there trying to hold your hand and pull you into coding. That's because there are!


Search for "Learn to Code" and you'll be hit with a wall of helpful and useful tools, texts, videos and tutorials. And, frankly, they're great! Never before have there been so many ways to start learning to code.





Unfortunately, in later phases the density of resources drops off fast. Anyone who's made the jump from beginner to intermediate can attest that there is a BIG difference between the amount of resources available when you first start out versus when you're first looking for help building things on your own without too much hand-holding.


This problem exacerbates as the amount of knowledge increases rapidly entering Phase III, and is one reason why we call that phase the "Desert of Despair". Once you get past this and start to become comfortable with what exactly you need to search for, the resources return and you're able to work with more technical tools like industry blogs and screencasts. Part of this is just understanding which questions to ask.


Here's what the Resource Density looks like in each phase (greater line density indicates more resources):




Density of Resources in Each Phase -- Click to Enlarge



Factor 2: Scope of Knowledge


Now let's talk about a related issue -- the Scope of Knowledge. This represents the total breadth of new topics you need to learn in each phase. Here's what it looks like:




The Scope of Knowledge that's Required in Each Phase -- Click to Enlarge





When you first start learning, the set of things you need to understand is narrow. Everyone, regardless of goals or language or background, needs to figure out what a for loop is, how to build conditional logic, and other basic structures of programming syntax. There ultimately aren't even that many of these fundamental concepts so the Scope of Knowledge during that phase is very narrow.


As soon as you get away from the basics, you see a rapid broadening of the Scope of Knowledge as you need to begin picking up things that are more difficult like understanding errors and when to use the code you know know how to use. This is different because there is no "correct" answer to a clear question... things get fuzzy.


When you progress into the third phase, the scope of knowledge balloons wider. You now need to understand what tools to use, what languages to learn, underlying CS fundamentals, how to write modular code, object-orientation, good style, and how to ask for help (to name just a few). Every trip to Google or Hacker Newstakes you down another set of rabbit holes and overwhelms you with more things you don't know but feel like you should.


You don't know what you don't know.


Only when you've finally found some traction and left the desert does the scope again begin to narrow. By that point, you've found your chosen technology and its place in the ecosystem. You finally (pretty much) know what you don't know and can plot a path through it. You will continue to increase focus as you push onward and into the beginning of your career.
Phase III: The Desert of Despair


With an understanding of these factors, you can see that the Cliff of Confusion is really just a turning point. The pain caused by the toxic combination of a rapidly increasing Scope of Knowledge and a falling Resource Density results in what I call the "Desert of Despair".


In essence, this desert is where you know there's an end somewhere but you don't know how to get there:




The Desert of Despair





The desert is long and fraught with dangers. You'll find yourself drawn to "Mirages of Mania" along the way -- dozens of tempting resources which appear to hold the solutions you're looking for but which will deposit you, once again, in a place where lonely sand extends to each horizon line.


Maybe you sign up for a couple MOOC courses from Coursera or Udacity or edX. Or you find a tutorial which purports to take you all the way. You thought you learned the lessons of the Hand Holding Honeymoon -- that there are no easy answers -- but the temptation to seek salvation is too great and you fall for the promise that this one will get you to the finish where the others did not.


You can't learn this stuff in a week or a month or a single college class no matter what anyone says so stop falling for that!


There is a LOT more to learn than you probably expected. Even if you're able to get some apps running, it's hard not to feel lost in the greater scheme of becoming a true professional. It's difficult to measure your progress. How do you know what you need to learn or if you're even learning the right things?


Even if you're pointing the right direction, it's hard to measure your progress. You might feel totally lost until the very moment when you're finally able to build something that looks and acts the way you expected it to. But, with enough perseverance and a good compass, you'll eventually get your first few "real" projects launched and you'll realize that you're finally starting to get it.


Sure it's been hard up until now, but maybe this web dev stuff isn't so bad after all... Everything's coming up Milhouse!



Phase IV: The Upswing of Awesome


You've made it through the desert and your confidence is growing. Your Google-fu is excellent and you're finally able to understand those detailed industry blog posts and screencasts. Maybe you've gone deep into a particular language or framework and you have confidence that you can build and launch a functioning application.


This is the "Upswing of Awesome":




The Upswing of Awesome





All may seem well to the outside but you know deep down that you're not there yet.


You can make that application work but what's happening beneath the surface? Your code is duct tape and string and, worst of all, you don’t even know which parts are terrible and which are actually just fine. Your periodic flashes of brilliance are countered by noob mistakes and, worse, a creeping suspicion that you still don't have a damn clue what you're doing.


This is a bipolar phase. You feel like half of you is a bulletproof developer and the other half is a thin veneer of effectiveness covering a wild-eyed newbie who is in way too deep. The further you progress, the more a gnawing sense of uncertainty grows that someone is going to "out" you as a fraud.


You feel like you should be a developer already but the distance between the code you're writing and a "professional" work environment couldn't feel further away...


Eventually, though, you'll make it. There's too much momentum not to! The Desert of Despair is behind you and the Cliff of Confusion is a distant memory. You're finally, truly, on the upswing. You're learning faster and more intelligently than ever before and, eventually, you will have absorbed enough best practices that your swiss cheese knowledge coalesces into a production-grade skill set.


The Upswing of Awesome always takes longer than you expect it to and it feels interminable because you're so close... but you will get there. If you're persistent enough in the right ways (the topic of a future post for sure), you will convince someone to pay you to keep learning. The job is yours.



What it All Looks Like


So now you've seen the road ahead and the reasons why it can be difficult. When you combine all four phases we just covered with the factors that define them, it looks something like the following chart:




The Whole Shebang -- Click to Enlarge





It's one thing to know the path and another to walk it. Let's get you started on the right foot.
How to Make it Through Alive


The journey seems intense and, frankly, it often is. It's important that you understand what you're in for, particularly if you go it alone. But you don't have to. There are ways to short-circuit most of these problems. Learning to code is rarely as easy as people make it out to be but it's also rarely as difficult as it seems in the depths of your despair.


In this section, I'll introduce the key tactics you can use to keep yourself pointed in the right direction.




Your Progression Through the Phases -- Click to Enlarge



I: Surviving the Hand-Holding Honeymoon


The plethora of available resources in the Hand-Holding Honeymoon make it a lot of fun. They do a great job easing you into the kind of logical thinking you'll need to cultivate over the coming phases. It's a great time to start learning to code so try to enjoy it and keep these two tips in mind:
Start by trying out different resources to find how you learn best and what sorts of projects are the most interesting to you. Maybe it's Khan Academy's quick challenges, Codecademy's in-browser exercises, Chris Pine's Learn to Program book or Code School's wacky try Ruby experience. Be open minded at the start and ignore anything about what you should learn... all code is the same at this phase.
Then pick one resource and stick with it once you've found your fit. Work through to the end of their introductory course arc, which should give you all the foundational knowledge you need to write basic scripts and apps. Then get ready to start building on your own.
II: Surviving the Cliff of Confusion


Almost everyone will experience the Cliff of Confusion because the only way to become a developer is to, well, develop. You can pretend to be building by signing up for tutorials (or tutorials which masquerade as "complete" courses), but you're just putting off the inevitable. Tutorials are a good way to bridge from more high-touch introductory offerings but you'll need to wean yourself off the pacifier and face the real world at some point.


Three tips for making the transition to building on your own:
Work with someone else, even another beginner. You'll be surprised how much easier it is to debug an impossible error when sharing two pairs of eyes.
Read other people's code to get comfortable with good patterns. Try to understand why the author did what they did. You wouldn't try to become a novelist without reading books as well, would you? We'll focus on this in an upcoming post but, for now, keep your eyes open for any small problems or projects that other people have written solutions for.
Start small and build constantly. You should have interesting big projects in mind for the future, but you'll need to get comfortable debugging and searching for resources with bite-sized challenges. There's really no substitute for experience.
III: Surviving the Desert of Despair


Once you've become comfortable debugging, your biggest problem becomes the fire hose of required knowledge and a total loss for how to learn it all... the Desert of Despair. In this case, what you really need is a strong path forward. The Mirages of Mania represent all the interesting side paths and rabbit holes and get-skilled-quick schemes which ultimately waste your time.


So the keys to getting out of the Desert of Despair are:
Have a strong goal for what you want to accomplish because otherwise you will end up chasing your tail learning all kinds of interesting but ultimately unproductive things. If you have the time to spare, by all means skip this...
Find a strong path which leads directly to the goal you've set and verify that it will actually get you there. This is where you need to dig deeper than the marketing slogans and smiling faces on course websites or book jackets to ask "will this help me accomplish the goal I've set or not?"
Focus and avoid distractions because, if you're the kind of person who's interested in learning to code, you're also the kind of person who gets interested by learning all kinds of other awesome things. When coding gets difficult, you need to be able to push forward instead of just trying out the next cool-looking thing.


If you're able to identify a path and stick with it, you'll eventually push forward to the next phase instead of spending months or years chasing mirages across the shifting sands of the this desert.
IV: Surviving the Upswing of Awesome


The Upswing of Awesome is one of the trickiest transitions. You can develop applications but you really want to become a web developer. Getting past this phase and into a job requires you to do three things:
Seek and follow best practices for programming. You need to understand the difference between a solution and the best solution. Best practices are a major difference between hacking on your own and building production quality code in a real job setting.
Check your assumptions because you've probably skated by with some gaping holes in your knowledge that you didn't even know you had. You need to diagnose and fix these holes.
Tackle the unsexy skills that are rarely addressed but highly important for transitioning into a professional setting. This includes things like testing, data modeling, architecture and deployment which are really easy to breeze past but which are totally fundamental to good development.


The key to accomplishing these things and pushing through the Upswing of Awesome is to get feedback. Students who have learned entirely on their own may be productive but rarely have the kind of legible, modular, and maintainable code that makes them attractive in a professional setting. You need to work with other humans who will challenge your assumptions, ask piercing followup questions, and force you to fix the leaks in your bucket of knowledge.
So... Can it be Done?


This all may sound overwhelming but I promise that many others have persevered and survived this journey before you. By understanding the road ahead, you're already in a good spot to take it on with a focused plan and access to the right kind of help.


Obviously there isn't space in this particular post to dig as deeply into each phase of the journey as we'd like or to provide the kind of granular how-to advice you deserve. That said, this is a journey with which we're quite familiar and about which we're highly passionate so we want to help in any way we can.


Our core program is specifically designed to bridge this whole process but, if you're interested in following along on your own, we'll be addressing it publicly and in depth during future blog posts as well.


Sign up below if you'd like to come along for the ride as we dig deeper into everything here -- from finding a mentor to bridging the gap to a fulltime job in web development. Because, though it's a challenging road ahead, you don't have to walk it alone.

Thursday 23 November 2017

TIL

from collections import defaultdict
a = defaultdict(int)

a[whatever] += 1 # without ever initializing for any whatever key

Sunday 5 November 2017

Tech Advice from ./

1. Get away from Gmail. Use a privacy-friendly alternative e-mail service like Startmail or ProtonMail. Yes, you will probably have to pay. You are either paying cash or paying with your data.

2. Break off Google search. Use DuckDuckGo to keep your searches private. If you want Google results, use Startpage instead; it will search Google privately on your behalf, preventing it from monetizing you.

3. Ditch Chrome. If you love the UI, then use the open source Chromium instead. Otherwise use Firefox (which is about to get a LOT better with the new overhaul debuting later this month) or Brave. Use your browser with ad blockers like Disconnect, uBlock Origin, AdBlock Plus and Privacy Badger to stop Google and others from serving you tracking ads.

4. If you use an Android, consider running CopperheadOS on your phone. It is built on Android code, but hardened for security and free of Google data mining.

5. Say no to Google cloud storage services. If you want a high security option, use SpiderOak. Otherwise, you can use Boxcryptor to locally encrypt your files before sending them to the cloud so that they cannot be data mined.

Reply to This

Monday 30 May 2016

What is the single most influential book every programmer should read?

From Stackoverflow
  • Code Complete (2nd edition) by Steve McConnell
  • The Pragmatic Programmer
  • Structure and Interpretation of Computer Programs
  • The C Programming Language by Kernighan and Ritchie
  • Introduction to Algorithms by Cormen, Leiserson, Rivest & Stein
  • Design Patterns by the Gang of Four
  • Refactoring: Improving the Design of Existing Code
  • The Mythical Man Month
  • The Art of Computer Programming by Donald Knuth
  • Compilers: Principles, Techniques and Tools by Alfred V. Aho, Ravi Sethi and Jeffrey D. Ullman
  • Gödel, Escher, Bach by Douglas Hofstadter
  • Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
  • Effective C++
  • More Effective C++
  • CODE by Charles Petzold
  • Programming Pearls by Jon Bentley
  • Working Effectively with Legacy Code by Michael C. Feathers
  • Peopleware by Demarco and Lister
  • Coders at Work by Peter Seibel
  • Surely You're Joking, Mr. Feynman!
  • Effective Java 2nd edition
  • Patterns of Enterprise Application Architecture by Martin Fowler
  • The Little Schemer
  • The Seasoned Schemer
  • Why's (Poignant) Guide to Ruby
  • The Inmates Are Running The Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
  • The Art of Unix Programming
  • Test-Driven Development: By Example by Kent Beck
  • Practices of an Agile Developer
  • Don't Make Me Think
  • Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
  • Domain Driven Designs by Eric Evans
  • The Design of Everyday Things by Donald Norman
  • Modern C++ Design by Andrei Alexandrescu
  • Best Software Writing I by Joel Spolsky
  • The Practice of Programming by Kernighan and Pike
  • Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt
  • Software Estimation: Demystifying the Black Art by Steve McConnel
  • The Passionate Programmer (My Job Went To India) by Chad Fowler
  • Hackers: Heroes of the Computer Revolution
  • Algorithms + Data Structures = Programs
  • Writing Solid Code
  • JavaScript - The Good Parts
  • Getting Real by 37 Signals
  • Foundations of Programming by Karl Seguin
  • Computer Graphics: Principles and Practice in C (2nd Edition)
  • Thinking in Java by Bruce Eckel
  • The Elements of Computing Systems
  • Refactoring to Patterns by Joshua Kerievsky
  • Modern Operating Systems by Andrew S. Tanenbaum
  • The Annotated Turing
  • Things That Make Us Smart by Donald Norman
  • The Timeless Way of Building by Christopher Alexander
  • The Deadline: A Novel About Project Management by Tom DeMarco
  • The C++ Programming Language (3rd edition) by Stroustrup
  • Patterns of Enterprise Application Architecture
  • Computer Systems - A Programmer's Perspective
  • Agile Principles, Patterns, and Practices in C# by Robert C. Martin
  • Growing Object-Oriented Software, Guided by Tests
  • Framework Design Guidelines by Brad Abrams
  • Object Thinking by Dr. David West
  • Advanced Programming in the UNIX Environment by W. Richard Stevens
  • Hackers and Painters: Big Ideas from the Computer Age
  • The Soul of a New Machine by Tracy Kidder
  • CLR via C# by Jeffrey Richter
  • The Timeless Way of Building by Christopher Alexander
  • Design Patterns in C# by Steve Metsker
  • Alice in Wonderland by Lewis Carol
  • Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig
  • About Face - The Essentials of Interaction Design
  • Here Comes Everybody: The Power of Organizing Without Organizations by Clay Shirky
  • The Tao of Programming
  • Computational Beauty of Nature
  • Writing Solid Code by Steve Maguire
  • Philip and Alex's Guide to Web Publishing
  • Object-Oriented Analysis and Design with Applications by Grady Booch
  • Effective Java by Joshua Bloch
  • Computability by N. J. Cutland
  • Masterminds of Programming
  • The Tao Te Ching
  • The Productive Programmer
  • The Art of Deception by Kevin Mitnick
  • The Career Programmer: Guerilla Tactics for an Imperfect World by Christopher Duncan
  • Paradigms of Artificial Intelligence Programming: Case studies in Common Lisp
  • Masters of Doom
  • Pragmatic Unit Testing in C# with NUnit by Andy Hunt and Dave Thomas with Matt Hargett
  • How To Solve It by George Polya
  • The Alchemist by Paulo Coelho
  • Smalltalk-80: The Language and its Implementation
  • Writing Secure Code (2nd Edition) by Michael Howard
  • Introduction to Functional Programming by Philip Wadler and Richard Bird
  • No Bugs! by David Thielen
  • Rework by Jason Freid and DHH
  • JUnit in Action
  • Discrete mathematics for computer scientists


Wednesday 4 November 2015

Favorite Apps

Mac:
Notational Velocity

Web:
http://momentumdash.com/


:more coming

Monday 2 November 2015

Saturday 1 August 2015

Monday 25 May 2015

All Islamicspirituality bayans

Can be downloaded by running this command on Linux:

Thursday 7 May 2015

What are mistakes which software engineers make in the first 1-2 years of their career?


  1. Not being willing to learn new languages and skills. Not willing to read technical books.
  2. Making assumptions where information is needed and instead of raising them just coding things up with the assumptions.
  3. When looking for help, asking for more than a  general direction, expecting people to do the groundwork and still expect them to help you the next time.
  4. Not paying attention to performance: Use of good Data Structure and Algorithms.
  5. Not paying attention to design: Design Pattern, Object Modeling, Best Practices
  6. Not paying attention to security: SQL Injection
  7. Not paying attention to testing: Writing test cases. Thinking of only happy flows and testing the success scenario with a belief that you're done with the code if that runs (in reality far from it).
  8. Documentation: Improper logging and comments.
  9. Descriptive Variable and Functions names.
  10. Blind copy paste making an assumption that it would work.
  11. Forget to take backup and remove all debugging statements like System.out.print before application goes into production.
  12. Not detecting and removing code that is obsolete due to your changes and letting it fester around to confuse and astound others.
  13. Jumping directly on solution. Don't start solution hunting the moment you face a problem or bug. Even if you copy from others solution, don't forget to learn and understand the solution.
  14. Expecting you can read intent and tone in email communication.  (ASCII does not contain facial expression or intonation.) Actually reading the whole email without making any assumption.
  15. Not focusing on career development and networking.
  16. Not asking for code review and help.
  17. Starting with a know it all instead of a learn it all attitude.
  18. Paying less attention to domain, understand who the users are and why they use what we build. Understand the environment the user will be in when using your program.
  19. Not able to provide reasonable/reliable estimates for the task in hand. At times they become too much optimistic and give strict deadlines while other times they estimate the task much bigger than it actually is.

Friday 2 May 2014

Faith - all that you need


Bits bout Typography

It's not a typo, I omitted the a on purpose. What purpose? Hahahaha...

So, one of these days, in the finals week, I decided, that instead of studying for my exams, I should read up some articles on Typography. After all, that's what one should do after one has spent the entire night typesetting one's resume that one has already submitted, before the exam day. What better way to escape from responsibilities than developing you aesthetic sense?

My exams aren't over, so I am still reading. Haha

So I googled, and came upon a number of nice looking polished articles. Finished one, the other one had links to four more, opened them up. Though 'Hey! This is cool stuff, I should bookmark it!' and discovered they were already in my bookmarks, and I hadn't read them. So I thought, might as well read them this time.

So one of them, is a very nice tutorial for beginners. I already know this stuff. But well, didn't I tell you about the important things to do before exam? Yeah...

So, this one site Interactive Guide to Blog Typography is an interactive type to blog typography. Hahaha... I mean it's really nice. As you can already see, all the rules the blogger mentions are already in place on my blog. But I will summarize them below. Why? I think by now you know better than to feel this curiosity.

Summary:

  • Frame the content with whitespace
  • Don't have distracting elements next to text
  • Measure: 50~90 characters in a line are good for readability
  • Leading should be 1.5em. For longer measures, increase; for shorter ones, decrease
  • For titles, set tracking = 1.1
  • Use one font. At most two
  • For body copy, use fonts that are hinted (mathematically adjusted to be used on pixel grids)
  • Use big enough font size for body copy. Recommended: 16px. I personally like 18px. Use even bigger for fonts with smaller x-height (like Crimson Text). Since I use such fonts, I guess that's why I like 18px
  • Create Visual hierarchy with font sizes. Don't pick font sizes randomly, size2/size3 should have the same ration as size1/size2. Another designed makes the analogy of 'Font scale' with musical notes. Either they're in harmony, or discord. So choose wisely. You can use modularscale.com
  • As in print, don't use the darkest black. Use like #444 or #222
  • Use small caps. But in cases where they don't exist, and you use font-variant (as in my blog) the problem is clearly visible, as the text appear lighter than its neighbours

Other Good Resources for Typography

Typography

Immaculate typography is certainly the most brittle of all the arts. To create a whole from many petrified, disconnected and given parts, to make this whole appear alive and of a piece - only sculpture in stone approaches the unyielding stiffness of perfect typography. For most people, even impeccable typography does not hold any particular aesthetic appeal. In its inaccessibility, it resembles great music. Under the best of circumstances, it is gratefully accepted. To remain nameless and without specific appreciation, yet to have been of service to a valuable work and to the small number of visually sensitive readers - this, as a rule, is the only compensation for the long, and indeed never-ending, indenture of the typographer.
— Overheard on the Internet

Wednesday 24 July 2013

Password Fuss

Important information from Ubuntuforums.org

Hello,

You are receiving this message because you have an account registered with this address on ubuntuforums.org.

The Ubuntu forums software was compromised by an external attacker. As a result, the attacker has gained access to read your username, email address and an encrypted copy of your password from the forum database.

If you have used this password and email address to authenticate at any other website, you are urged to reset the password on those accounts immediately as the attacker may be able to use the compromised personal information to access these other accounts. It is important to have a distinct password for different accounts.

The ubuntuforums.org website is currently offline and we are working to restore this service. Please take the time to change your ubuntuforums.orgaccount password when service is restored.

We apologize for any inconvenience to the Ubuntu community, thank you for your understanding.

The Canonical Sysadmins.

I recieved this email today. I made an account on these forums, and I never used it. And I don't remember which password I used. I think I used the password that I use on all forums. But not on other sevices.

And then people ask me, why I make such a fuss over having a different password for all my web services. 

Sunday 17 June 2012

Don't give me a designer's job

I am a programmer by profession. It’s the job I applied for; it’s what I have studied for, for over four years. It is also, what I am ‘good’ at; I think I am a natural programmer: the kind of person who naturally thinks methodically and doesn’t make assumptions, a person who feels comfortable only in definitive, deterministic circumstances. It is also, what I like. I would solve a programming problem just for fun, I would use programming to do petty (hehe…) real-life tasks, and on any given day, I would rather solve a programming puzzle than write an essay.

But, I design too.

Narcissism aside, I am really good at design too. I love typography. Beautifully set books literally turn me on (take that to mean what you may, but they actually raise my heartbeat, make me excited). I can look at font specimens for hours (and can spend more hours on the internet ‘finding’ them). I have produced some much appreciated artworktoo. I have been known to express complex mixtures of ideas through my designs. And I spend more time at this than any other activity that I don’t get paid for (save for sleeping, that's still a winner).

But, that’s not what my job is. It’s not my profession. It's true that I have done free-lance graphic designing in past, but even if I was offered a full-time job at the place where I currently work, I would not accept it. You see, I don't like to design what I am told or how I am told. They say that the mastery of the art is to work with constraints. As the constraints become tighter, skill is needed even more. And I agree with that. But for me, designing is not a task, it's not work that's to be done. I can't design for a paycheck. I can't take guidelines from someone when designing. I can't find the sweet spot between unbound artistic expression and deadlines. I design for myself, to give form to my feelings. I can't design to please anybody.

When I did freelance, I enjoyed what I produced. But the journey to that end was very tiring. It was exhausting, consuming, sometimes, even frustrating. I get obsessive about little details. And so, after hours and hours of judgment, I would settle on something, and just for a second opinion, show both versions to someone, and they couldn’t tell the difference. That part was very frustrating. Also, because I lacked the formal training in this field, I had to read so much just to get one theme in line with color harmonies, or one layout in line with natural design. And guess what? My clients couldn’t tell the difference. So I thought I couldn’t design for money. Or for people.

Don’t get me wrong, I like appreciation. I like it when others like what I do. But that’s not the reason I design for! It's true that if I came up with a ‘masterpiece’ and Asad comes along and says, ‘err… Saad, the tracking on this one's a bit off…,’ as much as I would like to tell him to go screw himself for belittling my child, I would not. I would probably think, ‘My boy does need a haircut’ and I would adjust the tracking. But Asad's approval is not why my child came into the world. That happened cause I wanted to make love.


Monday 30 April 2012

Software Construction

So I am reading this book that my colleague recommended, Code Complete by Steve McConnell. It's supposed to contain the best practices of software engineering, without which, not only your software is mediocre, it's also very expensive.

The book makes it clear early on that it's only about the Software Construction part of the software development life-cycle, but does talk about what to assess before doing construction. So it does talk about what're the steps before it.

Here's the life-cycle as the book mentions it:
  • Problem definition
  • Requirements
  • Architecture
  • Construction
  • Systems Testing
  • Future Improvements

What I was surprised to learn is that problem definition really has to be just the problem. It can't contain any solution in it, and it can't contain any technical terminology. It should state the problem, as faced by the User, in User's words. Only then can the requirement analysis be unbiased and most suitable. 

From the book:
A problem definition defines what the problem is without any reference to possible solutions. It’s a simple statement, maybe one or two pages, and it should sound like a problem. The statement “We can’t keep up with orders for the Gigatron” sounds like a problem and is a good problem definition. The statement  “We need to optimize our automated data-entry system to keep up with orders  for the Gigatron” is a poor problem definition. It doesn’t sound like a problem; it  sounds like a solution. ...

Suppose you need a report that shows your annual profit. You already have computerized  reports that show quarterly profits. If you’re locked into the programmer mind- set, you’ll reason that adding an annual report to a system that already does quarterly reports should be easy. Then you’ll pay a programmer to write and debug a time-consuming program that calculates annual profits. If you’re not locked into the computer mind-set, you’ll pay your secretary to create the annual figures by taking one minute to add up the quarterly figures on a pocket calculator. 
— McConnell, S. (2004) Code Complete.

Thursday 19 April 2012

Tahoma

Tahoma is one good font. Looks great for bodies of text, when your body text is 8 pt. For example,
In the central portion of the great North
American Continent there lies an arid and repulsive
desert, which for many a long year served
as a barrier against the advance of civilisation.
From the Sierra Nevada to Nebraska, and from
the Yellowstone River in the north to the Colorado
upon the south, is a region of desolation and silence.
Nor is Nature always in one mood throughout
this grim district. It comprises snow-capped
and lofty mountains, and dark and gloomy valleys.
There are swift-flowing rivers which dash
through jagged canons; and there are enormous
plains, which in winter are white with snow, and
in summer are grey with the saline alkali dust.
They all preserve, however, the common characteristics
of barrenness, inhospitality, and misery.