Category Archives: Development

Let’s Talk about Pre-Processors Like it’s 2010

By Chris Bartek

Reading some of my past entries, you’d think I hate pre-processors or something. Well, that’s not quite right. Setting aside the obvious (PHP, etc.), I want to have a quick discussion on the pre-processors that have been popular over the last few years, and my take on them.

SASS & LESS
Great ideas, but pretty much the same thing. They don’t offer any real benefit over old-school CSS for small projects, but they’re certainly useful for the larger ones. But you know what’s better? Stylus. Stylus seems to take the whole idea a step further with the whitespace syntax.

CoffeeScript
Mixed feelings. I used it on a project recently, and while I love how easy it makes OOP and the syntax is lovely compared to the mess that is Javascript, it seemed to have a few frustrating quirks, and whitespace syntax is not always your friend. But then again, it beats getting lost in the “});});” forest. Debugging can quickly become frustrating as well.

HAML
I won’t lie, I can’t stand HAML. I want to like it, but the fact is HTML, like XML, is incredibly well suited for, well, markup. Here is an example of the number one reason HAML drives me nuts:

HTML
<span class="test">this</span> <strong>is <a href="test/" target="_blank">a</a></strong> <em>test</em>

HAML
%span.test this
%strong
  is
  %a{:href => "test/", :target => "_blank"} a
%em test

…so what happened here? Well, I traded a simple, common line of text for a mess of carriage returns, indents, hashrockets, and… colons? why?… and at the same time made it more difficult to read. I saved 20 characters, but at the expense of readability, and I made my brain hurt. HTML. Isn’t. A. Programming. Language. The verbosity of XML serves its purpose, like it or not. Although like everyone else these days I use JSON over XML most of the time, when you are dealing with lots of inline data, it makes more sense to use XML instead. Repetition and verbosity != not readable. This just doesn’t seem like the solution to any kind of problem HTML might have had. A better solution? Stick with HTML, and for templating, use mustache.js (the only Javascript-based templating engine that doesn’t suck, in my opinion).

Oh, and if I ever said anything mean about Node.js, I take it back. Without that, none of this would be possible. 🙂

Leave a reply

The Legend of Grease Weasel

By Chris Bartek

Have you ever wondered what it’s like to fire weasels out of cannons at extreme velocities? Then check out my new game, The Legend of Grease Weasel, available now on iTunes, Google Play, and Amazon Appstore!

While you’re at if, if you’re using a Kindle and want to check out my games, all of my apps are now available on the Amazon Appstore (except for SoulTrade… yeah, they didn’t like that one).

Grease Weasel has actually been done for 6 months or so… I dunno why I’ve been sitting on it all this time, but there you go. It really needs more stuff added, like a “how to play” screen. Pro-tip: press anywhere on the screen when going downhill to speed up. That’s pretty much all you need to know.

Have fun!

Leave a reply

The Icosahedral Fortune Telling Apparatus

By Chris Bartek

Another day, another app. This week, it’s my Magic 8 Ball clone, The Icosahedral Fortune Telling Apparatus. This app actually has a long, complicated history. It was orignally called “Magic 4 Ball” but that didn’t please Apple and Mattel. After 3 name changes, it became this ridiculously long, generic name (abbreviated as TIFTA) to eliminate the possibility of trademark infringement. Moreover, the 4 ball shape was eliminated from the list, and it finally passed review. And it’s a good thing it did, because the next name was going to be abbreviated “FMATTEL”.

So there you have it, after over a year of trying to get this small, lame app through the App Store, it’s finally here. Not really worth the wait, but oh well. Sometimes more important things get in the way of progress. This was the first game app I ever wrote, so go easy on me.

Android
iOS

Leave a reply

Presenting my latest project, SoulTrade

By Chris Bartek

As you might have guessed, I’ve been working on another app these past few weeks. This represents only 2 weeks of work, so overall I’m okay with how it turned out. Without further ado, I present:
SoulTrade (soultra.de)
(available for iOS and Android!)

What is SoulTrade? It’s a market for buying and selling souls, basically. Yeah I know, it’s a pretty stupid idea, but I mostly just wanted to flex my design and development muscles with some of my free time. I really didn’t care what the website did, as long as I got to use PHP/MySQL/jQuery/Javascript/HTML5/CSS3. So ironically, this project really has no soul, heh.

Technical details: SoulTrade was written by me in 2-3 weeks with a PHP/MySQL back end using my own framework. The front end was designed by me in Photoshop and Dreamweaver, and of course utilizes HTML5/CSS3/Javascript/jQuery. The website is running on a LAMP stack, while the mobile version is using jQuery Mobile and Phonegap.

Enjoy.

…mwahahaha….

Leave a reply

Banned from the App Store!

By Chris Bartek

So Apple called me to personally reject my newest app.

Not surprisingly, they don’t believe my app is really doing anything. In a way, they’re right, I guess. Basically, what the app does, is it matches people who want to buy human souls, with people who want to sell them. People pay money for human souls, that’s what it does, but it also doesn’t involve any sort of tangible transaction, and Apple’s problem is they don’t want users involved with metaphysical transactions. They also said souls don’t exist and they cannot be sold (how dare they say this to a Doctor of Metaphysics, haha). So there you have it; if you ever wondered if Apple believes in souls… no, they don’t.

You know, I’m not even going to rant about it… I’ve been doing way too much ranting these days. I guess I’m just disappointed that they disagree that the app does anything. I saw the rejection coming a mile away, I just didn’t know which part of the guidelines they were going to dig up to keep it from hitting the App Store. It took them 3 weeks to figure it out, heh. So no, I’m not going to get angry about it, because I find it way more amusing than anything else.

Unfortunately, I’m not sure there’s a way to go forward with this project without it getting rejected again. Either you believe the soul transaction is ocurring, or you don’t. Apple says if the business model changes they will accept the app, but I’m not really willing to do that. Therefore, I will no longer pursue publishing this project on the App Store. I may, however, attempt to create a bookmarkable web app to circumvent the App Store.

Look for a new app announcement within the coming days…

Leave a reply

Custom Accordion Snippet using jQuery

By Chris Bartek

Whenever I’ve built my own accordion script in jQuery, it’s always had the same problem: when you click on the collapsible that’s already open, it closes itself, then immediately reopens. Looking for alternative accordion scripts, I’ve noticed everyone else’s seems to have the same problem, so I came up with a deliciously simple way to solve it.

First, a little background. The reason this is happening is completely logical and due to the synchronous nature of jQuery animation. The way most developers go about their accordions is to make sure all others are closed, then open the requested accordion. This method works great unless you want to be able to close an accordion. Without further ado, here’s the easy solution:

HTML:
<div>
<h2>First</h2>
<p>Content</p>
</div>
<div>
<h2>Second</h2>
<p>Content</p>
</div>

Javascript:
$(document).on('click', '.collapsible h2', function(evt){
$(this).addClass('clicked');
$('.collapsible h2:not(.clicked)').removeClass('selected').next().slideUp(500);
if($(this).hasClass('selected')){
$(this).removeClass('selected').next().slideUp(500);
} else {
$(this).addClass('selected').next().slideDown(500);
}
$('.collapsible h2').removeClass('clicked');
});

Easy, right? Embarrassingly so. But I didn’t see any good examples online, so here you are.

Update 4/10: Fixed a bug in the :not selection.

Leave a reply

A Beginner’s Guide to Publishing on iOS and Android

By Chris Bartek

Submitting apps to Google Play

  • Pay the $25 one-time fee.
  • Sign APK with your keystore.
  • Upload the APK.
  • Upload screenshots and metadata.
  • Hit publish.

Total time: 5 minutes.

Submitting an App to the App Store

  • Pay $99 a year.
  • Wait for Apple to dig through your articles of incorporation, then approve your membership.
  • Apple tries to call your corporate attorney at 7:30 PM on a Friday and can’t figure out why he’s not answering.
  • Apple ignores your emails asking them to call you back. Restart process.
  • Obtain an intermediate certificate. Install into Keychain.
  • Whitelist any devices you’ll be using to test with.
  • Create development and distribution provisioning profiles for your app and system.
  • Generate your certificate. Load everything into Keychain.
  • Find out you need the newest MacOS that just came out last week in order to compile.
  • Re-download the whole 5gb Xcode. Find out that there is now no backward compatibility with older iOS.
  • Link up certificates to your Xcode project.
  • Certificates don’t work for some inexplicable reason. Apple doesn’t know why. Revoke all certificates and go back to step 5.
  • Spend two days trying to figure out a half dozen unhelpful error messages in Xcode, in-between bugs, freezes, crashes, and file corruption.
  • Upload your icons and screenshots in dozens of sizes, including a 57×57 and 58×58 icon (WTF, seriously?).
  • Compile for Release and pray the certificate works.
  • Log into iTunes Connect and upload your screenshots (in 3 different sizes) and metadata. Mark it as ready for binary.
  • Download Application Loader and open. Don’t use open or create package, they don’t do what you think they do.
  • Navigate to ~/Library/Developer/Xcode/DerivedData and try to figure out which folder is your latest release compile.
  • Upload to Apple. If it rejects your certificate, even though it worked fine on your device, go back to step 5.
  • Now that you painstakingly rebuilt your certificates, you find out the release cert won’t run on your device. Ironically, Application Loader accepts it this time.
  • Wait anywhere from 1-3 weeks for Apple to review your app.
  • Your app will likely get rejected. They’ll give an oddly-worded explanation why, leaving you to guess what they want you to fix.
  • Have fun in Xcode. Go back to step 12.
  • Congratulations, your app has been accepted. Grab a bottle of scotch, relax, and watch the nickels come rolling in.

Total time: 3 weeks.

I guess this should be a great hint of what I’m working on right now.

Leave a reply

If I had a TED Talk, it would sound like this…

By Chris Bartek

Once upon a time, computers were invented. The idea was simple enough; feed the machine input, it processes per your instructions, and produces an output. The hard part was getting the instructions into the computer so it knew what to do. First, logic was hardwired. Then there were punchcards. These processes were incredibly time-consuming, so programming languages were written. Low-level languages like Assembler allowed the programmer to build software for the CPU itself… this was efficient, but still complicated, and would only work for that particular hardware. Higher level languages were created to abstract the hardware and software, and make things more programmer-friendly. This gave birth to COBOL, FORTRAN, and BASIC. However, it was discovered early on that these functional languages were not well-suited for complex applications. Languages like C++ evolved over the next few decades to make object-oriented programming popular. As languages moved away from concepts such as garbage collection, other concepts remained, like static typing.

Over a decade into the 21st century, PC productivity has evolved by leaps and bounds. We no longer do word processing using markup tags. We don’t use BASIC as an OS. We don’t poke around in PostScript code to build vector shapes and 3D models. We don’t hack around in Unix terminals to check our email. Event logging is not done using a dot matrix printer in a closet. So then, why are we are still using punchcard-era thinking in computer programming?

We need to demand better than this. We need to put an end to Notepad-style IDEs. End the command prompts. End the need for compiling everything to machine code. End the buffer overflows, freezes, crashes, hex hacking, and general security disasters. End the thousands of source files strewn across directories. End the hours wasted rebuilding for other architectures. End the dozens of C++ and LISP copycat languages and admit they were never great languages to begin with. End the need for languages.

While everything else on PCs has moved away from languages, software development has not. Why is that? Is it because we’re too limited by RAM and HDD? Software is getting more complicated? We can’t afford for software to take longer than it needs to? No, no, and no. Why can’t we abstract things in a different way? Like simply use visual interfaces to snap together libraries of low-level logic, skipping high-level programming languages completely? Why does MVC and OOP have to involve hundreds of files, when it could simple be the way you choose to visualize your data, not necessarily how you physically organize it? Why not let the computer organize itself efficiently… why is the housekeeping our job?

I hope one day we will live in a future where the average developer doesn’t concern him/herself with text-based code, but instead concentrates on the tangible engineering aspects of their project. I see interesting projects that attempt to go this route, and I guess the biggest problem is the money and time involved in such feats. But in the IT world, wouldn’t it be so worth it? I know I’ve talked about these ideas a million times, but let me reiterate: Creating yet another programming language will not solve any problems; let’s instead come up with a plan to move away from programming languages.

Leave a reply

jQuery Image Slideshow

By Chris Bartek

Ever wanted or needed to make a slideshow system like you see on news websites? Here is a simple HTML/CSS/jQuery template to help give you a jumpstart. Here are some of the features:

– JSON-based input
– will handle a mixture of horizontal and vertical images of any size
– image descriptions can contain HTML tags
– navigate slides using buttons or arrow keys
– view and jump to slides visually
– automatic advance button
– shows thumbnails when hovering over slide buttons
– responsive layout (for mobile and iframe widgets. Non CSS3-based so it works in IE7 and 8)
– tested in IE8, FF, Chrome, Opera
– lightweight and easy to modify

I started working on a fullscreen mode for it, but got frustrated with the spotty browser support. I hope to eventually come back to that feature… but at any rate, here it is in 1.0 form. You can use it in your projects, but if it’s commercial, be nice and put me in the credits.

(DOWNLOAD COMING SOON…)

Leave a reply

MVVM Frameworks versus Unobtrusive Javascript

By Chris Bartek

So this has been bothering me, and maybe I’m underthinking this, but doesn’t it seem like Javascript frameworks these days are not only breaking the unobtrusive scripting mantra, but also breaking MVC? Example from knockout.js’s website:

knockout

Why on Earth would it be a good idea to “encapsulate data and behavior into a view model”, as their website suggests? Well, to “get a clean, extensible foundation on which to build sophisticated UIs without getting lost in a tangle of event handlers and manual DOM updates.” I’m really on the fence about this. While I’ve always suspected MVC can sometimes complicate development and refactoring, these days I live by unobtrusive scripting. HTML holds your structure. CSS holds your stylesheet. JS holds your business logic. SQL, JSON, XML, etc. hold your data. Why mix and match all that crap in your HTML file? Just because you can, doesn’t mean it’s a good idea, that’s why we all stopped doing that method years ago. And it’s not just Knockout doing this, it’s nearly every framework these days.

So to be fair, there are definitely arguments in some cases against MVC. Likewise, there are arguments against unobtrusive Javascript. For instance, jQuery event handlers can be used irresponsibly and make it easy for your designers to screw up the logic by renaming a class or restructuring the tag hierarchy. I’m definitely familiar with this. And with MVC, I can see the advantages of forsaking it in the backend for some projects since it’s often times building the view itself based on logic. However, in the case of Javascript, your view has already been generated so I fail to really see the benefit of decoupling them.

What is the best way to go about this problem? Honestly, we can chase our tails on MVC and UJ for another decade, but I think the only way to solve this is with smarter IDEs. Can you get “lost in a tangle of event handlers”? Sure, I guess. But you can also get lost in a tangle of MVVM… as a veteran of the “onclick=” era, you can trust me on that. We should demand a web development IDE that makes it easy to manage event handlers and functions, representing them visually in some fashion, and linking them to objects from the HTML side so we can instantly see what logic is attached to them. Then we won’t have to wade through tons of text files to locate what we want. This is the year 2013, why do we continue to pretend this problem doesn’t exist or doesn’t need to be solved?

I don’t mean to sound all negative; modern Javascript frameworks can do some cool stuff… automatic DOM updating, templating, ease of code generation from the backend, etc…. so for some projects, this is absolutely wonderful and perhaps merited, but honestly I can’t think of an everyday use for them that wouldn’t make things needlessly complicated. jQuery forever changed the way we code… it’s a great general-purpose framework that makes it easy to do event handlers and DOM updates, so in a way, doesn’t that already solve the problems that MVVM frameworks are trying to “re-solve”?

In closing, some of these MVVM Javascript frameworks infuriate me and make me want to develop my own cleaner, friendlier framework or IDE. It also makes me reflect on previous posts suggesting that we might be regressing back into 90’s web development; now I’m starting to think it really is happening.

Leave a reply