tag:blogger.com,1999:blog-26564480715412307532024-02-06T21:52:50.119-08:00CodingSucksILoveIt ... by Shaheed AbdolShaheed Abdol writes about how code shapes our world, and the coders who love to hate the code they hate to love to write ...Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-2656448071541230753.post-64843954861298124772023-09-18T13:30:00.001-07:002023-09-18T13:30:54.068-07:00Letters to my wife in case I don't make it part 1<p> My dearest wife,</p><p><br /></p><p>The world has been so cruel to us. First the world was hateful towards you in your youth, it hated me too in my teens.</p><p><br /></p><p>Next, the world took its sweet time keeping us apart for all those years. When we finally found each other, we were both already well spent from a lifetime of struggle.</p><p><br /></p><p>As if to add insult to injury, we've barely had the shortest decade together and now the world is ending. The world sits on the brink of war, while our beloved homeland sits on the brink of economic collapse and starvation.</p><p><br /></p><p>The sweet fragrance of the flowers of our youth has been replaced with masks as disease ravages our world. No more flowers will bloom when the last bee dies.</p><p><br /></p><p>Through all this, I've found you, and it's been fun. If the world takes me before I can say it:</p><p><br /></p><p>"I don't know what comes next, but I promise to find you in every lifetime. I'm so sorry that you might live this lifetime without me, I'll make it up to you in the next one, pinky swear."</p><p><br /></p><p>Your loving husband</p><p>In every lifetime</p><p>Me</p>Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-16906099499425889052021-05-13T12:34:00.005-07:002021-05-13T12:34:46.240-07:00Self-Motivation is hard!Ok, so it's been a while since my last update.
I've been grinding away at this game so hard, and made very little progress <a href="https://youtu.be/XaXr_d7UTww">as you can see here.</a> <div><br /></div><div>I've been grinding away at this game for a while now and I've learned a lot.</div><div><br /></div><div>The number one thing I've learned so far is that I should have spent a few weeks learning a really good game engine and then just used that. </div><div><br /></div><div>I've spent so much time just writing boilerplate and infrastructure, that I've yet to build a decent game. </div><div><br /></div><div>I remember complaining so much about the lack of game engine choices and how hard they are to learn - but, it's even harder writing everything from scratch. And when I say "everything", I mean EVERYTHING! </div><div><br /></div><div>I've created resource loading classes, scene management, view trees, sound management, audio queues, playlists, rendering pipelines, camera classes, starfields, parallax scrolling, state management. </div><div><br /></div><div>Everything, painstakingly written from scratch. </div><div><br /></div><div>For one redeeming moment I can at least say that I've learned an incredible amount of things - how to do things, as well as how not to do things. </div><div><br /></div><div>But if I may pass on some knowledge to you, it will definitely be this:
If your goals to learn, then do what I did, learn and create from scratch. </div><div><br /></div><div>Just don't expect to write a complete game this way. </div><div><br /></div><div>If your goal is simply to create a good game, then use a decent engine, somethig that has most of what you need. </div><div><br /></div><div>You'll get most of the way to your vision without the infrastructure getting in the way. </div><div><br /></div><div>Iff you have lots of time and you're a masochist, then join me, I'm in room 11 tearing my hair out.
</div>Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-41231583225484406812019-09-27T04:50:00.000-07:002019-09-27T04:50:04.903-07:00XBOX ONE Game Dev is supposed to be hard.So I recently took the plunge and joined the Xbox One Creators Program with Microsoft.
It turns out that it's supposed to be incredibly hard to build these little games we see all the time, and for the most part, it is.
Not only do we have to deal with the fact that the XBOX One does not use the stripped down PowerPC architecture that the Xbox360's used to run on, we now have to contend with the fact that it's basically running Windows 10.
I remember the good old days when win32 and GDI (Graphics Device Interface) were sufficient to get a decent game running on a Windows PC - especially if the game wasn't too resource intensive.
Then came Direct(X/3D/2D/11/12) with all its COM (Component Object Model) Glory -> which, perhaps most asinine of all -> is still being used today.
Getting into the creators program costs a little bit of money, and that's mostly to keep the chancers out and cover administration fees. After that you really only need to abide by the store policies and be able to write a little bit of code, then you're sorted.
With the advent of Xbox One-Friendly game engines, it's easier than ever to build an app that runs on a Windows 10 PC as well as the beloved Xbox One.
I remember the good old days where things needed to be rewritten and recompiled to be able to run on different platforms . .when developing for a console required the teams to purchase a Dev-Kit (Development Kit containing an unlocked piece of console hardware) in order to be able to write their code.
I remember when the costs were prohibitively expensive, and a simple guy - like myself - would never be able to justify spending that kind of cash on a hobby.
I remember when it took teams of people to build an idea, a game, a concept, a business with big-budget marketing, in order to break-even on the Xbox Live Marketplace.
I remember when NDA's (Non-Disclosure Agreement) had to be signed so as not to divulge the inner workings of the console.
I remember . .. .
These days it's stupidly easy to publish an app to the Microsoft Store, and by extension the Xbox Live Marketplace ->
Step 1) Sign up for the creators program (this requires a small sum of money)
Step 2) Peruse the numerous tutorials and reference materials Microsoft makes available online.
Step 3) Build your desired game
Step 4) Publish to the store
Those are literally the steps, and Step 3 is simplified vastly if you use the Unity Game Engine with the Xbox Live plugin -> this abstracts away all the tedium of setting up your project keys to be included in your application.
All in all, one could go from 0 all the way to Step 4 in a little under a week if they were motivated and had lots of spare time.
So, yeah . . . I think I've found something that was supposed to be hard, that's been made incredibly easy along the way.Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-21798714490525377962018-04-17T06:30:00.001-07:002018-04-17T06:49:08.114-07:00Finding a Game Engine is Hard<p>Well, if you're new here - congratulations on finding the most useless blog on the planet.</p>
<p>If you're not new here, thanks for coming back to another installment of "And he just keeps moaning!",
this weeks episode deals with how hard it is to select a <a href="https://en.wikipedia.org/wiki/Game_engine">Game Engine</a> for your development needs.
</p>
<p><a href="https://codingsucksiloveit.blogspot.co.za/2018/03/a-few-thoughts-on-game-development.html">As I've mentioned in the past,</a> there are many things to consider when developing a game: </p>
<ul>
<li>Storyboarding</li>
<li>Specification document</li>
<li>Game Engine</li>
<li>Resources (art / sound / levels)</li>
<li>Time constraints</li>
<li>Return on Investment</li>
</ul>
<p> Since I've preached about the Specification Document all throughout <a href="https://codingsucksiloveit.blogspot.co.za/2018/03/a-few-thoughts-on-game-development.html">my last post</a>, I'll save you a little bit of reading by saying it's nearly the most important part of the entire process - nevermind having a compelling game - without the specification document, nothing gets built.
</p>
<p>
Storyboarding is kind of like the specification document, but it allows you to draw little screens of the game as you imagine it to be, without too much detail. And it allows you to have a visual tool which you can move around to help with explaining the flow of the game to other humans.
</p>
<p>
Resources are simply all the files (images + textures + sprites, sound clips, music tracks, font images etc) which your game relies on to have the look and feel you desire. Many people get stuck on this bit - they can't draw or sketch and they can't find that very unique image online that represents what they are imagining. Most guys give up at this point, since it's easy to mock up a prototype online - there are tons of resources that allow you to prototype a scene, there are very few hidden resources that help you find or create the artwork you see in your minds eye.
</p>
<p>
One thing I have to mention is that, in a strict sense, you could view other humans as resources. For instance, I usually think of myself as a resource for code, so when I start a project that requires a developer, I write my name down in the resources section of my planning document. Knowing that I'm a resource allows me to better plan for my own utilization during project development - understanding that I can only churn out so much code for so many hours per day is paramount to helping me limit the reach of what I touch. If you only have 1 developer resource, then you're better off trying to find more <b>Human Resources</b> to better manage the workflow.
</p>
<p>
Time constraints are simply a measure of how long each item in your task list will take to complete divided by the total amount of time you want to spend on the project. This is a simplistic view at best, since some tasks take longer than others to complete, and its up to your Human Resources to help you in this phase of planning. Developers are notorious for underestimating the amount of time tasks will take, try to add 'padding' around time estimates from developers as they're only human and sometimes run into unexpected issues.
</p>
<p>
Return on Investment is a simple calculation of how much each planned feature will contribute to the overall perceived success of the project - notice I use the word "perceived" as it's not known at development time how successful the product will be, it's only known how much each planned feature will contribute to the perceived value of the product.<br/>
As an example - if you're developing a knife, it's better to spend more time working on the strength and flexibility of the blade than it is to nitpick over the colour of the engraving on the handle - and yet, some product planners seem to get this wrong.
</p>
<p>
I've seen several instances where a huge amount of importance is given to certain features because the perceived value of the feature is inflated due to personal bias. In this regard, it's best to find an impartial observer and show them a mock-up of the product with and without the feature to gauge their response. This is similar to <a href="https://en.wikipedia.org/wiki/A/B_testing">A/B Testing</a> and helps tremendously with product design, yet it's often overlooked.
</p>
<p>
This brings us to the topic of todays <strike>Moaning Session</strike> Post. The Game Engine.
</p>
<p>
I've personally seen some inexperienced teams plan out an entire game - yes, from start to finish, with storyboards and careful resource allocation charts - without even mentioning which Game Engine they're going to use.
</p>
<p>
You might find this fairly hyperbolic, but I assure you - it's very easy to overlook the Engine, after all - the Game Engine is just a set of classes with which your code interfaces that "takes care of" (tm) the low-level details so that your developers can get on with writing the code for your awesome game.
</p>
<p>
While this is true, it's also not 100% accurate since there's a cost involved in selecting a specific engine. If your team isn't intimately familiar with the engine, there's a huge learning curve - especially for larger engines, which you'd have to take into account.
</p>
<p>
If you'd allow me to make a tangential example - it's kind of like training to run a marathon, <b>while running the actual marathon</b>. I'm not even exaggerating, this is almost exactly what it's like to pick up a new Game Engine and start using it in production from day one.
</p>
<p>
My recommendation is to try to find people who are familiar with building projects using the engine you're trying to use, else there's a lot of internet searching you'll have to do to get everyone up to speed with how things work.
</p>
<p>
I recently embarked on this mission myself, but I had the luxury of not really caring too much about any Game Engine in particular - I'd had some experience with Irrlicht, a little bit of dabbling with other Engines, but I had nearly 0 experience with Game Engines which target Android.
</p>
<p>
This relative inexperience put me in a unique position of having to slough through tens of engines to find something even close to what I needed. Unity was almost immediately disqualified - not only does the editor devour my machine resources when I start it up, but I'm not too happy with the coding language access and implementation they're using.
</p>
<p>
Unreal was totally unreal in their licensing model. Irrlicht was also disqualified, since I wanted the engine to be easily usable inside Android - mostly written in Java and I wanted the engine to hide the language bindings from me where they've chosen to use C++ for speed boosts.
</p>
<p>
Godot looked fairly promising based on user reviews, until I went and read up a bit of their documentation - the moment they mentioned <a href="https://scons.org/">Scons</a> my eyes glazed over and I rejected Godot. There's no way I'm unleashing that dragon.
</p>
<p>
Most of the other engines I researched had one limitation or another that didn't sit well with me. Some had strange licensing terms, others had tough build systems, and yet others were written using non-Java-like syntax and naming conventions.
</p>
<p>
I can appreciate as much as any other developer how hard it is to learn conventions that are specific to a language and the community built around them - Java code can be written to look much like C++, but the two communities differ and therefore the accepted language conventions differ as well. When writing something as utilitarian as an Engine, all that's required is a firm grasp of the language specifics - Memory management and Object construction, in order to write a decent engine. One could argue that good engines are constructs which can be written in any language, and naming conventions and language specificity only serves as fluff.
</p>
<p>
I'm not going to argue the point above, but one could . . .
</p>
<p>
Since I've spent a fair amount learning Android development by building Android apps and games, I've spent a fair amount of time just learning to understand the basics of the development process. This is something I've never bothered with - since I'm self-taught, and never cared about that much, since most of the good development skills are language agnostic in any case. I've paid special attention to Android, as this is where I believe I'd like to fit in, so to speak.
</p>
<p>
When I write Java code on Android, I'd like it to look as much like the code which Google releases as possible, naming conventions an all. So I've paid special attention to Java since I'd like to continue developing in it and be able to blend in seamlessly with the online communities around it - and the most obvious way to stand out is to not be aware of the unspoken conventions surrounding the language.
</p>
<p>
With all this in mind - as well as the fact that it's easier to be productive in an environment that's familiar, even though it's new. I embarked on my mission - scanning through tens of engine entries on search engine pages, scouring forums and articles. Perusing blogs and StackOverflow questions and answers until only one Engine stood out among the rest.
</p>
<p>
Enter <a href="https://libgdx.badlogicgames.com/">libgdx</a> - as much an engine as a library, it has it all: <a href="https://libgdx.badlogicgames.com/features.html">Feature List</a>
</p>
<p>
Even though it's cross-platform, when I develop on Android, it <b>feels</b> like Android, it's nearly immediately obvious which class I should instantiate, or how to do it, since it feels so familiar. With this in mind - it has great performance and a substantial list of helper classes to ease my job. Their documentation is also some of the best I've seen in a while, and I'd highly recommend anyone who wants to get anything serious done on Android to give it a shot.
</p>
<p>
More important than all of that - their build system didn't require me to change anything about my development environment - all developers know what I'm talking about: you get your IDE set up nicely the way you like it, then you select a Game Engine and are forced to abandon your IDE and reach for your Terminal (Command Line on Windows) because the Engine does something that requires it.
</p>
<p>
With libgdx you can develop with Eclipse or Android Studio - it's supported by Gradle and allows you to continue working on your mock-up without changing much apart from a few class names.
</p>
<p>
There's also the question of file size, since Android games can reach into the hundreds of megabytes these days, I wanted an engine that didn't add that much overhead to the size of the resultant APK, and this is where libgdx really shines - I followed a tutorial which contained 2 images and one WAV file and checked the size of the resultant APK, around 4.5MB which is significantly smaller than most of the other engines I'd looked at.
</p>
<p>
I'm really being picky here, but I'd like for my supporting engine code to not outweigh my own game, and this is something I find very important on mobile devices - especially in my country, where mobile data is exceptionally expensive, and most people opt for the 'Lite' versions of almost any app they choose to download - if I want a shot at the local market, my app needs to be as small as possible.
</p>
<p>
While I could go on all day about the benefits of libgdx, I'll leave it at what's already listed - you could go read more about it <a href="https://libgdx.badlogicgames.com/features.html">over here</a> if you really want to - after all, who better to tell you about it than the people who built it.
</p>
<p>
In closing, you're more than welcome to use any engine you wish, after all you'll select based on criteria that is unique to your project - but please make sure you take into account that any engine selection comes with a learning curve, and that learning curve needs to be accounted for in your Time Constraints considerations when planning your projects.
</p>
<p>
I think, in total, it took me about a week to make my final selection, and that's only the beginning - now the real fun starts.
</p>Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com1tag:blogger.com,1999:blog-2656448071541230753.post-29484302283136663262018-03-27T04:57:00.000-07:002018-03-27T04:58:55.324-07:00A few thoughts on Game DevelopmentFor those of you who follow my blog, you'll notice that I talk about building games, but I never really release anything useful or fully playable.
I'm more interested in studying the individual parts of game development, without really caring about building a game as a whole.
Well, for the most part this is perfectly acceptable, as I'm not a game developer by trade, and my bread and butter comes from being a utility developer. I've defined utility developer as someone who codes a variety of things without specializing in any specific discipline. As a self-taught developer, it's been hard for me to pivot into a role where I'm classed as a game developer by trade.
This is all good and well, but I still want to talk about game development as a whole - specifically how to get a game off the ground.
If you've been following any blog about game development, or any programming course which walks you through the process, you've most likely heard of all the jargon - the game-loop, the culling phase, rasterization etc. But what you've been deprived of is the most important aspect of developing the actual game - the Bible of game development, the be-all and end-all which can make or break your project.
What could this all-important thing be which nobody seems to mention?
Well, simply put - it's the spec document for the game. The game design document.
I've seen many sites teach you how to make a game, but fail to mention that they're working from a spec (specification) - which tells them how each feature is going to work, how everything ties together. The spec document ties together which bits of the game interact, and also - and most importantly - defines the scope of the project.
Without a spec document, many teams end up in a death march - adding features which won't really benefit anyone, without having a definite project scope to allow them to cull the fluff. This causes deadlines to be missed and projects to be abandoned.
While one may argue that this is an archaic way of developing software, I'd like to argue that the spec document is very much alive - in Agile it's the "user story" and all associated notes which go with it. In more traditional projects, it's defined on some system - like Redmine or some other such software . . either way, there's always a definite set of features, a plan on how they will interact, and a deadline for when they should be ready.
It's easy to suffer from featuritis (feature-creep or feature bloat) without a definite spec for a game, adding in features because they might look cool. I've done this myself - to some extent - just for fun. But if I were to attempt anything resembling a real game, I'd spend a definite amount of time building up a spec document - including storyboards for how I envision the end product. You see, with a standing spec (one that's not expected to change, and one that's to be adhered to) the developer can filter out all the noise and focus on simply building the features which have been clearly defined in their game bible. With a valid spec document, the developer doesn't have to think about which features to add or remove - the set is well-defined and should be fairly fixed for the duration of the project. And because all the features are mapped out, there's a clear interaction model which helps the developer understand how all the features work together.
For example - I've recently started working on a spec document for a game I'm designing. Without a spec document I would've still been stuck trying to build it for multiple platforms, or trying to decide how to implement useless features. With a standing spec, I can clearly understand what the game should look like when I'm done, and how the features tie together. With my standing spec document I can make certain choices about how I'm going to implement the game - because I know a bunch of things in advance about the game.
Let's take a short walk through one aspect - which platforms will the game support?
Well, based on my spec, I expect the user to interact with the game using only 6 buttons [up, down, left, right; a, b] which can be represented using a joypad or joystick as well as 2 individual buttons. This layout is reminiscent of the old NES game controllers if you exclude the 'start' and 'select' buttons.
Based on this information, I can make decisions on how to minimize my Time-To-Product, which is essentially how much time is left before your planned release date. Given my sparse input requirements, I can safely say that I *could* realistically support many different controllers, but each controller type requires a bit of code to tie the button mappings to the game. I will be working on the game on my own, and can't really lay money on the table to invest in different controller sets, so supporting controllers will have to go into the next release cycle. With the current requirements I'd wager that it would be a good bet to reuse a joystick component that I've already written . .but my joystick component is written in Java - easy enough to port, but why port it?
If I have a reusable component, that gives me a visual joystick - developed for touch-screen games, you can see where this is going. Based on the game style, and gameplay mechanics - it would be beneficial to not have to worry about controllers and input devices, perfect the game would work nicely on touch screen devices.
So, just based on having a high level overview of the game I can decide on the game platform. With the platform decided, I can focus on building an interaction that's tailored to that platform, instead of trying to write something so generic as to not be playable anymore. I know there are great success stories of platform-agnostic games, but they have teams, and I have me.
With the platform out of the way, we can also start to revisit some of the user interactions - for instance, I've left a space open for 'special inputs' which could mean gestures - Android is great for this, and it's perfect for interacting with a game world since the user can gesture on in-game objects to get some kind of feedback.
Non-android touchscreen platforms are also viable, but I'd like to keep my costs low, and since I don't want to pay $99 per year to be enrolled in the Apple Developer Program, I think I'll exclude that market demographic from my potential client base. This is not a stab at the demographic - it's a stab at Apple, if they open their platform a bit to be more inclusive, I'd be less angry with them - some of us are living in Third-World countries, and $99 could feed our families for a month.
So, with this in mind, it stands to reason that I'd like to explore some game engines to simplify the process - instead of rebuilding the wheel, I could worry about the contents of the cart instead. I've found a few options that look very promising - oxygine (C++) and Gideros (Lua) seem to do the job quite nicely.
With the time investment (minimal available time) I'd like to leverage some of my existing knowledge, but if the chosen language is less productive than required, then it might be beneficial to learn a more concise language to get the job done - that's why Lua is in the running.
I hope this little thought-exercise has opened your eyes as to the kinds of high-level decisions that can be made when one has a spec document from which to draw information. Not only have we managed to pinpoint our exact platform - we've also managed to narrow down the list of potential game engines down to only 2 candidates, this is not usually an easy choice since there are literally a ton og engines out there - maybe I'll write a post on it next week - stay tuned to find out.
Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-55023854559537669012018-03-19T06:50:00.000-07:002018-03-19T06:50:10.428-07:00Typescript is HardSo, for a work-project, the language choice handed down by the Overlords-Of-Jobbing has been TypeScript.<br />
<br />
You see - where I work, we build websites, and we build the infrastructure to support those websites. We also build platforms to support the website-supporting-infrastructure . . . so we like to iterate quickly and be as agile as possible in our workflow.<br />
<br />
For the current clientele we're servicing it has been decided that TypeScript on the Babel toolchain would be the most productivity-boosting language we could use, and as a result I've had to learn this new-fangled language with all its idiosyncrasies.<br />
<br />
Now, TypeScript is awesome, it supports both static and dynamic typing, lambdas, the entirety of JavaScript and all the associated libraries and frameworks which come with JS.<br />
TypeScript is awesome.<br />
<br />
TypeScript:<br />
- will mend fences<br />
- paint your garage<br />
- spay your cat<br />
- neuter your dog<br />
- rent Clerks II on DVD<br />
- run you a nice hot bath after a long day<br />
<br />
But, the more I tried to "learn" TypeScript, the more I realized that TypeScript was missing something fundamental, something so earth-shatteringly basic that I couldn't even wrap my head around it.<br />
<br />
Before I reveal this missing piece, let me just dive into how awesome TypeScript is. One of the interesting things that makes JavaScript great for beginners, is the very permissive language rules. Essentially, in JS, if you're guessing that something "should" be typed (on the keyboard) in a certain way, then you're probably going to get the right syntax without much hassle. As I was learning JS, it kept occurring to me how often my syntax guesses were actually right, let me give you an example.<br />
<br />
In JS, if you were to try to declare an object of some type, which held some variables, there are several ways to do it:<br />
<br />
<pre>// To define an object of type "Person"
// 1
function Person(first, last, age) {
this.firstName = first;
this.lastName = last;
this.age = age;
}
var myFather = new Person("John", "Doe", 60);
// 2
var Person = {
init: function(first, last, age) {
this.firstName = first;
this.lastName = last;
this.age = age;
}
};
var myPerson = Person;
myPerson.init("John", "Doe", 60);
// 3
var Person = function (first, last, age) {
return {firstName: first, lastName: last, age: age};
};
var myPerson = Person("John", "Doe", 60);
</pre>
<br />
<br />
While these are all subtly different, they're similar enough to allow a n00b to forget about the hassles of syntax and get on with his task. Please allow for some syntax/logic errors as I don't have the desire to fire up my trusty editor right now to verify it all compiles.<br /><br />Enter TypeScript - the vast, all-knowing language must-have that will cook your dinner and spoon-feed it to you when you want.<br />
<br />
TypeScript does something unique - it imposes a formal syntax as the one and only expected way to create objects -<br />
<br />
<br />
<pre>
export class Person {
var firstName: string;
var lastName: string;
var age: number;
constructor(first, last, age) {
let self = this;
self.firstName = first;
self.lastName = last;
self.age = age;
}
};
let myVar = new Person("John", "Doe", 60);
</pre>
<br/>
<br/>
With this being said, I'd like to point out that I'm still very happy with TypeScript at this point. We've got well-defined classes, we've got inheritance, heck - we even get interfaces and proper types which throw compilation errors when you try to stick a string into a numeric type. All is still good and well in the land of TypeScript.
So what's the glaring problem, you ask?
Well, I was implementing something the other day, and I realized I'd need a linked list in order to allow for the nice dynamic insertions, removals and lookups I wanted. Arrays in TypeScript, I think even in JS are based on linked-lists, but I really wanted the code to reflect this as it was code that not-only was the basis of a larger feature-set, but also code that I may not be maintaining directly after release. I really wanted the implementation details to be crystal clear for any coder at any level, and a linked list is the universally accepted data structure on which my solution is based. I could have put a comment in the code about how the arrays are based on linked-lists, I could have changed my solution - but no. It's a universally accepted solution, well tested and well taught. It's also a universally understandable solution - granted that you have the correct data structure supporting it.
So, I started typing import 'LinkedList' from ...
When I realized that my IDE didn't know what a linked-list was . . . strange.
I went to Google, and tried to search for it there, given how TypeScript comes with some of the default containers one would normally want . . .but nothing.
Interestingly enough, I found some libraries which add this data structure and some more, but those would cause an external dependency which I was trying to avoid. That's when it dawned on me.
TypeScript has an incomplete Standard Library!
Yes, you are welcome to flame me and hate my guts, but it's true. If one were to look at Python, PHP or even C++ for that matter, you'd find that their std::* or 'It-Ships-With' library set includes most of what you'd want. However TypeScript does not.
I can appreciate that the language is lean and mean, but this caught me by surprise - standard data structures are something I kind of took for granted, especially since I had spent some time in Python and C++ building an eBook formatting system and never ran into this problem - not even once. C++ especially comes with a 'First Create Matter' mentality, so I was expecting it, but their standard library is second to none. PHP is geared towards HyperText, but again - their standard library is second to none, especially given what the language was intended to do.
But for something this trivial, to have to roll my own (Yes, 20 minutes well-spent: Writing the class, and some unit tests to prove to myself it was working) just boggled my mind. Fair enough, it's only 1 data structure, in 1 language, for a fairly standard thing one would be expected to do on a browser page, but still . . . it would have been nice.
After a lot of searching and reading, I found that this was almost intentional - since the entire idea of TypeScript is to implement as little as possible over pure JS to keep everything blazingly fast, I can nearly forgive this, and since you have control over how the JS is emitted, it all becomes 1 large file, which means you don't force the browser to hit a remote site where all the third-party code is hosted. Also, many of the third party 'standard' stuff doesn't require attribution - even for commercial use, I can also forgive the lack of meaningful standard stuff . . . but what I can't forgive is the amount of time I have to spend researching the respective repositories - reading their issues list to find out if the developer fixes bugs quickly. Checking around the web to see if the component is being used by trusted sites and developers - if there's a community following etc.
With other types of languages, that's a given - C++ would have a nearly rock-solid standard library with official language versions, which have lots of documentation in 1 place . . . same with Python, PHP, etc.
So, instead of complaining, I propose that we all jump onto a single bandwagon - we set up a standard-library repo which typescript developers can check out if they need a clone of the C++ or Python standard libraries. I'll be putting something together at some point - purely by bundling my entire utils folder into a standalone repo and giving it some epic name.
So, while the language itself boosts productivity, it also kind of hinders it with the nature of the design philosophy, and that makes TypeScript hard.Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-63343664175919278292013-11-07T06:09:00.001-08:002013-11-07T06:09:06.601-08:00Footnote Summit 2013 (#footnotesummit)<h2>
Well, the FootnoteSummit has come and gone...</h2>
<div>
<br /></div>
<div>
Yesterday, I had the good fortune to be one of those able to attend the FootNote summit 2013, my company sponsored me, of course, just before tickets ran out.</div>
<div>
<br /></div>
<div>
Those who had the good fortune to attend, were wowed with statistics and information regarding Digital Publishing both nationally and internationally. We were treated to an awesome lunch, a "free" touchscreen stylus, a "free" 3 month subscription to Getaway Magazine ... a "free" lunch, and an awesome opportunity to make friends.</div>
<div>
<br /></div>
<h2>
Friends were made...</h2>
<div>
I had the rare opportunity to make friends with another "techie" named Arthur Atwell. We chatted a bit about his Paperight business, and I was able to shed some light for him on how to make EPUB3 documents... I have only recently discovered that it's possible to take an EPUB2 file and massage it into a valid EPUB3 file by a tedious process of manual editing... This is a post for another day though.</div>
<div>
<br /></div>
<h2>
Cards were exchanged</h2>
<div>
If any of you have watched a romantic comedy (or romcom) as it is widely known, you will undoubtedly remember a scene of some young woman exchanging numbers with some your guy ... much to the guy's excitement. That is kind of what happened at the FootnoteSummit, but in this case everyone was exchanging business cards... I swear, I have never seen so many people swapping business cards at one time in my life...</div>
<div>
<br /></div>
<h2>
Sadly the fun was over</h2>
<div>
At the end of the day, we had been wooed and wowed with presentation after fantastic presentation. There were global representatives from all facets of the digital publishing industry present to knock our socks off with demos of awesome new technologies...</div>
<div>
<br /></div>
<div>
But all the fun had to come to an end as the day closed at around 15:30, just enough time for us to beat the traffic in C.T </div>
<div>
<br /></div>
<div>
On the plus side, I was pleased to discover that in South Africa, I am one of the few people who understands how to take an existing EPUB2 document and edit that file so that we end up with a valid EPUB3 eBook, it's quite astounding to know that most people don't understand how to go from version 2 to version 3 without paying exorbitant fees to have the book redone...</div>
<div>
<br /></div>
<div>
Well, I enjoyed myself and learned a lot, le't hope that we are able to attend the summit next year too.</div>
Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-61772874203931818292013-10-23T07:29:00.001-07:002013-10-23T07:29:19.737-07:00So, after writing my several thousand lines of Python....<h2>
After I have written and DEMO'd the code...</h2>
I finally finished writing the several thousand lines of Python code, interspersed with HTML and CSS .. and provided my bosses with a very nice DEMO of what the app does... needless to say, the app was running on our intranet - off my machine, which was partially converted into a Server Node on out intranet...<br />
<br />
The bosses loved the app, they loved it so much, in fact, that they wanted it "out there" for the world to use!<br />
<br />
<h2>
Writing a web app in PHP is hard...</h2>
So, after writing all that awesome code in Python, it was time to start hunting for a new web provider which allowed Python 3 code ... none were forthcoming, and my bosses didn't like the idea of moving our website to a different provider ... so it was back to the drawing board ... to rewrite the entire thing in PHP ...<br />
<br />
<h2>
Well, PHP is not that hard ... when you know it...</h2>
<div>
In the defense of PHP, it's not really a hard language to master ... sure, there are a lot of functions, but nothing that is too insane to handle .. mostly, it's quite easy to learn and master ... but to write several thousand lines of code is another thing entirely.</div>
<div>
<br /></div>
<div>
I started by learning the basics - how to get it running on my Apache installation, how to "secure" the feature set... how to write the actual code, then it was time to slice the workload into pieces...</div>
<div>
<br /></div>
<h2>
Understanding the concept of PHP is not too bad...</h2>
<div>
It took me a while to get my head into the concept of PHP - calling functions right inside the HTML code, functions which return more HTML ... with Python, you formatted the code as you went ... with PHP you formatted your page, and plugged in the function calls you needed at the end ... </div>
<div>
<br /></div>
<div>
Once I got this distinction into my head, it was easy to implement the functionality needed to get my code running the way I wanted it to...</div>
<div>
<br /></div>
<h2>
The most useful function in PHP</h2>
<div>
The most useful function I have come across in PHP is the "include" statement... not only does it give you the option of including HTML source, it allows you to use one "header", "footer" or source file all over your site ... this has by far saved me the most time. Of course, my Python was as modular as I could make it, but the idea of including a "header" file, or a "common html" file eluded me because it required me to write code to get it done ... in PHP this is already done for you so when you become aware of this feature, you start using it as second nature.</div>
<div>
<br /></div>
<h2>
In conclusion...</h2>
<div>
In conclusion, I have to say that PHP is awesome, it simplifies several issues I have been having with Python, and it is blazingly fast ... Python is also pretty nifty when used right, but it costs you more complex code and several optimizations to make it as fast as possible ... in PHP one can write lazy code and still get away with a huge speed benefit. I must admit, that the learning curve is not as simple as I make it sound, but I can vouch for how much simpler it is to learn PHP than it is to learn Python ... probably because the syntax is so similar to Javascript and C++ ... </div>
<div>
<br /></div>
<div>
All in all, I have already ported 90% of the project in about a month ... and the original App took me three months to write. And, this time I'm not dedicating nearly as much "zone time" to it as I should.</div>
Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-32016969267531859202013-09-10T08:05:00.001-07:002013-09-10T08:05:14.651-07:00So, python web apps are not that hard after all<h2>
So, I was saying earlier that writing web apps with Python is hard ...</h2>
<div>
<br /></div>
<div>
I was sorely mistaken... Obviously, I am not using any frameworks to facilitate my project - which is a huge mistake, but a learning exercise for me (I'm fairly new to python). When not using a framework, you are exposed to the internals of how CGI and Python all meld together, as well as how to use the FieldStorage object to respond to Ajax requests.</div>
<div>
<br /></div>
<h3>
It's only hard if you do it the "wrong" way</h3>
<div>
Writing a web app with Python 3 is only hard if you do it the wrong way. I come from a background of coding C++ code using the most bleeding edge coding techniques - OOP, TDD, Templates, Multiple inheritance, Polymorphism, insert bleeding edge coding technique here, etc.</div>
<div>
<br /></div>
<div>
Now, this is all good and well when using a language like C++ where you only face the OS endpoints (Windows API, stdlib etc) at certain points in your code. But these techniques do not work too well when using a high level scripting language like Python. I started off by churning out dozens of classes which has get and set methods for any data members. I also tried to abstract away the basic Python functionality by writing classes which dealt with IO and repeated function calls...in short I ended up trying to write a framework on top of Python. This is all good, as awesome Python frameworks exist, but it was detracting from my main purpose - to get on with writing the app.</div>
<div>
<br /></div>
<h3>
It gets even harder when you just write what you need</h3>
<div>
By this I mean that I stopped writing my framework when I realized my folly, but then had to start over by only writing the code I needed. This is the hardest part of coding - writing the least amount of code to accomplish the highest level of functionality. This is the zen of coding, and it took me a while to find my sweet spot.</div>
<div>
<br /></div>
<div>
Of course, you need Database wrappers, you don't want to instantiate a SQLite3 console in the middle of iterating through your FieldStorage object to find URL parameters ... but you do want to have a handy function on hand so that you can take those parameters and do something useful during that loop.</div>
<div>
<br /></div>
<h3>
Getting it "just right"</h3>
<div>
I finally hit my stride when I had my fancy UML diagram all spec'd out and I was able to write only the classes I needed. Those classes, in turn, contained only the functions I needed, and after ironing out some kinks in my way of thinking about Python classes, I was able to bang out a decent web app in about 80 hours. Of course, I did not have the luxury of spending days on end adding classes all willy nilly, I had to squeeze in odd hours here and there to get it done.</div>
<div>
<br /></div>
<div>
The main thing I learned is that Python is awesomely powerful when it comes to manipulating data. Python 3 comes with a slew of features which allows one to have a working Ajax request handler in about 20 lines of code. I also learned that the true strength of Python shows through when you have finished your self-inflicted torture ie: "learning curve" and simply get on with the business of writing your app.</div>
<div>
<br /></div>
<div>
Python frameworks are there to abstract away the drudgery of having to code a "find key in dataset" algorithm for the 20th time, they save you from yourself when you do not know enough about the language to step around common pitfalls.</div>
<div>
<br /></div>
<h3>
The current trend is micro-frameworks</h3>
<div>
Todays developers have gotten slightly lazy in that they all rely on some framework. These days micro-frameworks are all the rage, and developers become burnt out after spending maybe an hour trying to digest the documentation for the latest and greatest framework. I prefer to stay away from all that because these frameworks fall into disuse and are forgotten and if you have gone 98% of the way into building a business using one of these forgotten frameworks then you either have to hire rockstar developers to save you from the framework, or you have to add improvements and workarounds for the last version of the framework on the planet.</div>
<div>
<br /></div>
<div>
These options are not really too usable for startups, and I can see why many startups bank on either technologies which have already found a firm footing, or on creating their own frameworks and platforms on which they can build their latest and greatest product.</div>
<div>
<br /></div>
<div>
I'm not saying it's wrong to use a new micro-framework, just that you should really weigh your options when deciding on your development strategy. I spent about 4 hours searching the net and becoming aware of the "abandonment trend", which causes developers to furiously write code using a new library, only to become frustrated when something doesn't work the way they guessed ... and the documentation has not quite caught up to all the new features - developers write code, great developers write code which documents itself, the greatest developers don't write code - they write documentation which executes at runtime. Chew on that for a second.</div>
<div>
<br /></div>
<h3>
Optional ranting</h3>
<div>
During my foray into writing my first web app, I discovered that many would-be Pythonistas are doing "the right thing" by writing everything themselves - excluding the kitchen sink. During their development they hit inevitable snags which could be solved by adding something to the language itself - like a way to say FieldStorage.findkey('key') ... which may or may not actually exist. But, the great part of these flaws is that patterns emerge, tried and tested functions become public knowledge after a developer bangs his head on his desk while solving a "simple" problem.</div>
<div>
<br /></div>
<div>
I ended up needing to send emails to users of my web app, I wanted a way to send the email, store it in the database, and store the resulting message off-site ... I spent a few hours trolling messageboards to find a solution when it suddenly hit me, like a slice of lemon wrapped around a brick - use gmail, which promptly led me down the rabbit hole in search of a way to send email... About an hour later I hit upon this little script, which must be the simplest way to send email which I have found: <a href="http://kutuma.blogspot.com/2007/08/sending-emails-via-gmail-with-python.html">http://kutuma.blogspot.com/2007/08/sending-emails-via-gmail-with-python.html</a></div>
<div>
<br /></div>
<div>
If you have copied the script and are now frantically struggling to get the interpreter to recognize your efforts, bear in mind that things have been reorganised in Python 3, by replacing the import statements with these statements, you should be able to get up and running in no time:</div>
<div>
<blockquote class="tr_bq">
import smtplib<br />from email.mime.multipart import MIMEMultipart<br />from email.mime.base import MIMEBase<br />from email.mime.text import MIMEText<br />from email import encoders</blockquote>
That little slice of code should save you lots of time when working with Python 3 and struggling to understand why seemingly innocuous import statements don't want to work..<br />
<br />
Well, that's enough of my ranting, my web app should go live within the next month or so - at which time I will make it available for public use. Until then, happy coding... </div>
Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-86372386503633718602013-07-30T11:44:00.000-07:002013-07-30T11:44:28.823-07:00Writing a home-monitoring system using python + internet...Hmmm, what's that, you say? A Python home monitoring system? Why would anyone want to subject themselves to that kind of abuse?<br />
<br />
Well, I , for one, amd lazy ... it shows in my work, it shows in my lifestyle, it shows in my weight .. and it shows in the way I write code. I'm the guy that will spend 2 days writing an app (which is available for purchase on the Google App Store) because I'm too lazy to get up and get myself a credit card ... because I'm too lazy to get up and scratch in the drawer for my old credit card so I can purchase stuff from Google Play ...<br />
<br />
Before you go ranting that I expend time and effort to write an app which costs $3 ... you must remember that I am a programmer .. code it like water to me - extremely bitter, and mostly salty water, but water nonetheless ...<br />
<br />
I eat code, I think code, I dream code and I can churn out code if I want to because it has become second nature to me. So it's simpler for me to just write it myself than it is to actually expend some physical effort to go and find something ... you cannot grep in the real world. You cannot hit [Ctrl][F] after opening your drawer. Frankly, I should patent some kind of "Reality Search" function which would apply itself to real-world objects ... but I'm too lazy to go down to the patent office to get it filed in person... Even if I could file patents online in my country, I would be too lazy to get up off my ass to go and use my new function...<br />
<br />
Which brings me to the crux of my post ... why would I use python for such a serious task? What I am trying to do is definitely non-trivial, but surely PYTHON?<br />
<br />
Well, the truth is that I am too lazy to go back to coding things in C++, I am not an Environmentalist, nor am I a packer ... I am more of a "mapper" who likes to interpret and adapt information into some kind of "view" which can be applied to knowledge ... and my "view" of the matter is that if I need the blazing speed to shoot myself in the foot a trillion times while simultaneously being bitten into millimeter sized pieces, then C++ is the way to go for every project.<br />
<br />
If I were to use C++, then I would have to either write little command-line programs which did something specific with some command line input ... and tie that into my server (I'm using Apache - it's easy to set up, and doesn't require any movement on my part) ... or I could churn out some high-level code using a high-level "interpreted", "dynamically typed" language like Python... which saves on compile time, debug time, the amount of keystrokes I have to bang out ... it saves on heart rate as there is less agitation, and it saves on breathing since there is less cursing...<br />
<br />
It's kind of a simple choice, really. For anything web-related, use web technologies ... for industrial "blazing speed", specialized applications, then get closer to the hardware with C or C++ ... For the record, I prefer the straightforward nature of C (I have spent several years coding industrial apps using C - if it's not straightforward, then you misunderstood something) but I love the speed you get when you can bang out a couple of object, an interface between them and then set them loose on the world of C++ ... so it's a trade off really. You just need to know which hammer will beat which nail, then all should be fine.<br />
<br />
So back to the app - it's a very simplistic application:<br />
<br />
<br />
<ul>
<li>Set up a "service" running in apache which allows an authenticated user to receive a screenshot containing all visible web cams on the home network.</li>
<li>Send these screenshots at some interval to the authenticated user.</li>
</ul>
<br />
This is fairly simplistic - since I will not even get into the hair raising mess of authenticating a user...<br />
The simplicity is in how one would collate the images and send them over the network ... it's fairly straightforward to get the images - leave the DVR software running all the time, and periodically take a screenshot using this function:<br />
<br />
<br />
import win32gui<br />
import win32ui<br />
<br />
def screenshot(_filename):<br />
wDC = win32gui.GetWindowDC(HWND_DESKTOP) #hwnd<br />
_w = win32ui.GetSystemMetrics(SM_CXSCREEN)<br />
_h = win32ui.GetSystemMetrics(SM_CYSCREEN)<br />
dcObj=win32ui.CreateDCFromHandle(wDC)<br />
cDC=dcObj.CreateCompatibleDC()<br />
dataBitMap = win32ui.CreateBitmap()<br />
dataBitMap.CreateCompatibleBitmap(dcObj, _w, _h)<br />
cDC.SelectObject(dataBitMap)<br />
cDC.BitBlt((0,0),(_w, _h) , dcObj, (0,0), win32con.SRCCOPY)<br />
dataBitMap.SaveBitmapFile(cDC, _filename)<br />
<br />
cDC.DeleteDC()<br />
dcObj.ReleaseDC()<br />
win32gui.ReleaseDC(HWND_DESKTOP, wDC)<br />
<br />
This would give me some image with a predetermined name which I could look up on the drive when I needed it ... I would probably store the images in a folder which represents the images from a specific cam on a specific day ...<br />
<br />
Loading up the image is easy ... displaying it to the user is equally easy ... write a little JS function which requests an updated image via Ajax at some interval... Embed an &lt;Object&gt; into the HTML, tie it to the JS and VIOLA! You have a bandwidth-friendly solution to a home-surveillance problem...<br />
<br />
This is obviously a gross oversimplification of the whole app, but it would definitely work along these lines ... I would obviously write some code (using PIX or Pillow) to convert the images to JPEGS on the fly either before saving, or at request time ... but the basis is the same. Obviously I would have to port forward on my router to allow that to happen ... but luckily <a href="http://www.dyndns.co.za/">DynDNS</a> has made that much simpler, and all the grunt work of getting it set up , and obtaining a DOMAIN with a dynamic IP has been taken care of .. I have even assigned a static IP to my "surveillance" box which runs the apache server .. so most of the setup work is done .. all I need to do is to tie in some way of getting screenshots at a specified interval - which is equally easy ... write a "backdoor" into the system whereby I can leave a browser window open on the same machine running some periodic Ajax function which would force the server to respond at some predetermined interval - when I get a specific Ajax request, then do the hard work ... very hacky, but sufficient for my purposes - I could hack this together in a day. Now, imagine doing all of that, AND writing the C/C++ code to back it up? Can you imagine the pain and agony and suffering you would go through simply debugging why X won't initialize before Y?<br />
<br />
If I wanted ultra-secure 128bit encryption and blazing fast real-time RTSP streaming web app, then I would be forced to resort to a C/C++ HTTP server which relies on the live555 media streaming library somewhere... and then write a C/C++/wxWidgets-backed client side which decodes and displays using FFMPEG... but, thankfully, I don't need to go that route just yet :-)<br />
<br />
Thanks to <a href="http://stackoverflow.com/users/432745/pyfunc">pyfunc</a> over at <a href="http://www.stackoverflow.com/">StackOverflow</a> for the screenshot function, which I am generally going to plunder from the SO site - as much as I plunder many lines of code from awesome coders who are not as lazy as I am.<br />
<br />
<br />
<br />
<br />
<br />Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-8950018043931000852013-07-30T04:48:00.000-07:002013-07-30T04:48:30.256-07:00On working with Python and Javascript .. and HTML and Ajax and SQLiteI have recently been creating a production management system. The system is not that complex, but it is taking an inordinate of time to write ... even though I am using rapid-prototyping languages - Python, SQLite3, HTML4/5, Javascript coupled with liberal Ajax sprinkles ...<br />
<br />
I simply don't understand - but I will try to get to the root cause.<br />
<br />
So far, I have constructed the tables and written a database backend wrapper - for the SQLITE3 DB which I manipulate on the server side using python cgi.<br />
<br />
I have created the concept of "sessions", but not in the MOD_PYTHON way, no, in the more traditional - hacky, store-it-in-the-window_name way ... By allowing the user to send an Ajaxlogin request, which generates a session token on the server side, which is then "kept" or "remembered" on the client side by storing the token in the window name browser object variable... It's probably the most rubbish way I can do it, but it works - survives page reloads (F5), survives navigation buttons (back, forward) ... and means I end up writing less python code to deal with IP-address-based-sessions since our network is mostly DHCP based, and we frequently restart our routers in any case due to some other technical difficulty we have to live with due to a third party.<br />
<br />
I have added support for individual "users" and am in the process of linking "projects" to users in a nice way.<br />
<br />
I have created an HTMLFormatter python script which can generate nicely formatted links which call JavaScript functions ...<br />
<br />
I have written JavaScript functions which append the session token to outgoing requests ...<br />
<br />
I have written more python cgi code which checks for session tokens and discovers which user "owns" the token and does something fancy with that ...<br />
<br />
<br />
I think I'm starting to notice a trend here ...<br />
<br />
Medium/Large frameworks hide all this detail from the programmer - allowing them to deal with the core of their code - the business logic. When writing something from scratch, we tend to spend an inordinate amount of time getting a trivial feature to work "just right", only to blow another week on it when we discover it bombs out in IE...<br />
<br />
When you are a hobbyist programmer, it makes sense to write as much as you can on your own so that you can both sharpen skill and learn a diverse set of code "katas". But when you are an experienced programmer who is simply trying to get a project "done", you don't want to spend 2 days learning how to handle sessions which do not use cookies ... you want to spend that time banging out the code that ties the project to the user and allows the bosses to draw up time sheets and plot graphs and all those other things that bosses do with production management systems....<br />
<br />
Even for hobbyist programmers I would recommend using frameworks for things you are already comfortable with - know how to implement sessions already? Use MOD_PYTHON for the next project which requires sessions - you know how it works, now use some code which saves you from 3 weeks of implementing it yourself.<br />
<br />
Keep it simple ... but simple is a very relative term - upon embarking on this project, my idea of simple was to have a simple "session" - based on the user IP, which displayed their own project queue to each user, and a more "admin" interface to the sysadmin. I spent about a day banging out some nice python/html/JS/Ajax code to get it all working nicely and discovered that my idea fell flat when the DHCP server (our router) was rebooted during a session ... so I spent some more time tweaking the idea to use ip + machine name ... but that quickly fell flat when I discovered that users on our network didn't have unique machine names ... and I wan't up to the task of renaming each machine to make my code work ... which is when I stumbled on the "shared login" concept - log a request to the server to get a session token, then associate the token to a user id on server side, and store only the session token on the client side - that way we don't care if the transport mechanism goes offline between requests - we simply send off each request with the session token and let the server handle the rest...<br />
<br />
This was by far the most robust approach I have found so far - now if only I could get it to work if the user suddenly starts working in a different tab .. hmmm ...<br />
<br />
Well, the only thing left to say is that python/JS/HTML+Ajax are "rapid prototyping" tools for a simple reason - somebody has already built the prototype, whether is is a python recipe or a JS library, it has been built - if you are going to keep inventing the wheel it will be slow in any language ... and will probably end up gathering many patches along the way, until it ends up like my project - which now consists of more patch than actual wheel ....Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-87510993125107940632013-05-23T00:36:00.001-07:002013-05-23T00:36:34.046-07:00Writing a Windows Gadget is hard!Windows Gadgets suck ... Microsoft has recently discontinued support for Windows Gadgets - in favour of Apps. So any Gadgets fans/freaks out there who might enjoy the challenge of writing a gadget ... like myself ... are out in the cold when it comes to sharing gadgets, or hoping for support on some Sidebar issues ...<br />
<br />
Well, it's not like they dismantled Windows Sidebar in Windows 7 ... but it looks like there is no gadget support in Windows 8 ... which kind of sucks because gadgets filled the instinctive need of many computer users to clutter up their desktop with cool techno-looking bars and charts and dials and switches etc...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtzfJe8oBGC5-Dif5oa7TCjNsrmVMiHqEclWH5K5oNafKkb6AkSmv3uER3IJEBiAkwZTJTJL_CRvKYy13Jy8u_BfmphXLJkNyzSvc2T1sXtxAmKjphvPYZsvr4P7bACXAVAuCaP8N-O-du/s1600/cluttered-desktop.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="232" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtzfJe8oBGC5-Dif5oa7TCjNsrmVMiHqEclWH5K5oNafKkb6AkSmv3uER3IJEBiAkwZTJTJL_CRvKYy13Jy8u_BfmphXLJkNyzSvc2T1sXtxAmKjphvPYZsvr4P7bACXAVAuCaP8N-O-du/s320/cluttered-desktop.jpeg" width="320" /></a></div>
<br />
So, Microsoft, in their infinite wisdom, decided to integrate most of the popular gadget functionality into the actual OS, instead of these little unrelated boxes floating around causing havoc with system resources...<br />
<br />
Well, disregarding everything I just wrote ... I decided to write my own gadget - it's still a work in progress, so don't laugh too hard... but I started by studying the gadget format - not too tough to master, basically a folder structure with some XML defining the main files...<br />
<br />
Then there is the gadget syntax - specialized html tags to identify elements of the gadget .. not too bad...<br />
Then there is the compulsory JavaScript - luckily I was already learning that... so not too bad there...<br />
<br />
Then there is the docking functionality... let me start by telling you that all the examples on the internet have one or other subtle flaw which my SideBar doesn't like ... while debugging the docking code I suddenly "lost" my gadget and it would not appear in the SideBar anymore .. well, ok, I mistyped something - but it's still frustrating to not have anything to debug with besides the tools which come with Chrome ... Oh, and did I mention that gadgets rely on the ActiveX components built into Explorer?<br />
<br />
That means that you can debug MOST of your gadget and Javascript code using Chrome ... but for all those Microsoft-specific things there is no actual way to DEBUG a gadget using Internet Explorer ... which is a shame because I rather enjoy playing with my TODOList gadget ... it's very simple, right now it can be docked - which shows a smaller list or undocked - which shows the same list in a larger view ... fun times :-)<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2eEj6Glqze-C9qJ000wdhq1nb7fCI8OpRlrPu5uJMgq6Eiix9qJe3gDHNAGl0UVJ0f01vEl19cb0sNDg5CkrhodT1Ht8IZAFjdTI6BD4f42HsufpaN0u92Xb6TVDBLSGTfN59YX2SuUF7/s1600/gadgets.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="153" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2eEj6Glqze-C9qJ000wdhq1nb7fCI8OpRlrPu5uJMgq6Eiix9qJe3gDHNAGl0UVJ0f01vEl19cb0sNDg5CkrhodT1Ht8IZAFjdTI6BD4f42HsufpaN0u92Xb6TVDBLSGTfN59YX2SuUF7/s320/gadgets.png" width="320" /></a></div>
My main plan is to refine the todo list to the point where I enjoy using it - and it will be my default app, since I am a programmer and my mind is inordinately full and prone to dropping details after all these years of juggling crazy amounts of things around in short term memory - plus there are a lot of distractions all around me, since I am the only programmer IN THE COMPANY... which is kind of awesome, The Lone Coder lol!<br />
<br />
Once the gadget has been refined to my liking, I would like to use it as a base for a gadget game I would like to write ... something like the old NES Star Force ... which is another mission on its own - but well worth the fun...<br />
<br />
So, gadgets suck, but the joy they bring definitely makes it worth the time and effort that goes into creating one...Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-68467197420338477362013-05-23T00:10:00.002-07:002013-05-23T00:12:24.569-07:00Building web apps with PythonWell, as much as coding sucks, I love it -so much in fact, that I spend an inordinate amount of time doing crazy things using the incorrect tools for the job at hand - just for the kick of getting it to work!<br />
<br />
Well, recently, I have been prone to the urge to use different languages to augment my website - for those of you who don't know, I am a software developer, who does web development in his spare time... Actually, my new job involves copious amounts of web development - but that is another story.<br />
<br />
Well, my current occupation allows me to do web development, and throw in "hardcore" programming languages into the mix - just for fun.<br />
<br />
So, one day I decided that our company intranet needed a way of sharing files - not a Samba share (Shared folder on Windows), not an FTP server - because FTP causes too much back and forth network traffic.... and certainly not using anything "standard" like PHP or JavaScript!<br />
<br />
No, I opted to use Python... So, I set up Apache, and got cracking ... mind you, it was not as simple as I thought it would be, but as it turns out, Python is quite capable of this task- with relatively little code ... It's quite simple, you edit your httpd.conf file to include python files to run as cgi scripts, which can then run in any folder... then you get cracking writing your python script...<br />
<br />
Of course, you would need a fixed IP for the server to be of any use, but it is rewarding enough to crank up your browser and see a web page that your Python code spat out...<br />
<br />
I have included a screenshot of the web app running - along with the tools which were created with it:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNyeBoowdBxpiBgS0jxzcoleVXpjV1FmaGmBTcVPQ0JDV1MfhrvAkHu9OVO0RB9-EcAR-Z9TZN1Ga7inkGAew9Zslb6ay7nK1RpqV3-qbJCfO5KL6H1eW515z83aaJrxLWnfGEUwFpvEje/s1600/internalserver.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="170" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNyeBoowdBxpiBgS0jxzcoleVXpjV1FmaGmBTcVPQ0JDV1MfhrvAkHu9OVO0RB9-EcAR-Z9TZN1Ga7inkGAew9Zslb6ay7nK1RpqV3-qbJCfO5KL6H1eW515z83aaJrxLWnfGEUwFpvEje/s320/internalserver.png" width="320" /></a></div>
<br />
*note that the image was doctored slightly to remove company information ... but the layout and look and feel are 100% correct. The left side shows the home page which lists all the services this app provides, and the right page is the "download" service running in my chrome browser window.<br />
<br />
Well, let me tell you that Python is quite a dream for writing web apps - especially to a C/C++ programmer who is used to banging out 1-3000 lines of code before morning coffee... This entire web app, with all associated services comes in at under 3000 lines of code - without refactoring to remove common code!<br />
<br />
Anyone interested in building web apps with Python should be aware that there are numerous security risks which Python is addressing as I type this. In the near future we might see python becoming the dominant web 2.0 language of choice for building awesome web apps.<br />
<br />
Have fun ... my next project is to write a Windows Gadget Game using JavaScript and some clever DOM tricks I picked up along the way...Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0tag:blogger.com,1999:blog-2656448071541230753.post-60213820160281486382013-05-22T08:01:00.000-07:002013-05-22T08:01:21.363-07:00Coding Sucks ... I Love It!Well, I have been coding since 2002 ... not too long, yes, but in that time empires have risen and fallen, billions of lines of code have been written, and I have learned one thing:<br />
<br />
<b>Coding Sucks ... I Love It!</b><br />
<b><br /></b>
Seriously, I can't get enough of it... I have written projects in Java, Python, C, C++, PASCAL, assembly (win32) ... most recently JavaScript ... each language (or scripting language) has it's dizzying highs and abysmal lows, but one thing is consistent:<br />
<br />
<b>They all suck</b><br />
<b><br /></b>
Yes, that is a cruel statement, but let's face it - all languages suck in one way or the other, templates in C++, no-classes in C, the ease with which Python allows you to destroy your project ... the inane simplicity of PASCAL (and lack of true graphics support + hardware accel.) ... There are pitfalls to any language - and yet I have coded in many of them, for one simple reason....<br />
<br />
<b>The feeling of triumph when I accomplish a milestone...</b><br />
<b><br /></b>
Or better yet - that feeling of relief when I complete a project.<br />
<br />
So, I might rant, and I might rave, but I have been coding for a long time - several of those years was as a Senior Developer at a software production firm, and I loved every second of the code - not the politics...<br />
<br />
I am a programmer, and this is my blog.Shaheedhttp://www.blogger.com/profile/16417029307642488010noreply@blogger.com0