Comments for Kinetic diagrams http://blog.kineticdiagrams.com delightful data-driven diagrams Wed, 07 Sep 2011 22:17:23 +0000 hourly 1 http://wordpress.org/?v=3.0.2 Comment on Inspiration for the weekend #1 by PartyPoker http://blog.kineticdiagrams.com/2010/06/18/friday-inspiration-victory-by-herbert-kauffman/comment-page-1/#comment-81 PartyPoker Wed, 07 Sep 2011 22:17:23 +0000 http://blog.kineticdiagrams.com/?p=46#comment-81 With havin so much content do you ever run into any issues of plagorism or copyright infringement? My website has a lot of unique content I've either created myself or outsourced but it seems a lot of it is popping it up all over the web without my permission. Do you know any techniques to help protect against content from being stolen? I'd certainly appreciate it. With havin so much content do you ever run into any issues of plagorism or copyright infringement? My website has a lot of unique content I’ve either created myself or outsourced but it seems a lot of it is popping it up all over the web without my permission. Do you know any techniques to help protect against content from being stolen? I’d certainly appreciate it.

]]> Comment on Experiment #1 – done! by Zac Boller http://blog.kineticdiagrams.com/2010/07/29/experiment-1/comment-page-1/#comment-75 Zac Boller Thu, 11 Nov 2010 20:30:18 +0000 http://blog.kineticdiagrams.com/?p=127#comment-75 It doesn't work for me. Though admittedly, I'm a about 4 months late to the party. It doesn’t work for me. Though admittedly, I’m a about 4 months late to the party.

]]> Comment on No updates this week by Jim Tran http://blog.kineticdiagrams.com/2010/08/06/busy-week/comment-page-1/#comment-71 Jim Tran Fri, 13 Aug 2010 05:14:28 +0000 http://blog.kineticdiagrams.com/?p=131#comment-71 "visiting" as an adjective, not a verb :) Planning on an October trip to SoCal though, so I'll be sure to tell you about it in November ;) “visiting” as an adjective, not a verb :) Planning on an October trip to SoCal though, so I’ll be sure to tell you about it in November ;)

]]> Comment on No updates this week by John http://blog.kineticdiagrams.com/2010/08/06/busy-week/comment-page-1/#comment-70 John Thu, 12 Aug 2010 22:53:32 +0000 http://blog.kineticdiagrams.com/?p=131#comment-70 Dude, you came down to CA to visit your parents and you didn't tell me so that you could stop by? I am hurt! Dude, you came down to CA to visit your parents and you didn’t tell me so that you could stop by? I am hurt!

]]> Comment on Inspiration for the weekend #4 by Jim Tran http://blog.kineticdiagrams.com/2010/07/09/inspiration-for-the-weekend-4/comment-page-1/#comment-39 Jim Tran Tue, 20 Jul 2010 10:51:20 +0000 http://blog.kineticdiagrams.com/?p=81#comment-39 Beykin, thanks always, for your consistent support of this project, it means a lot. Funny timing, you posted this link the very day before I picked up my first Android phone (a Samsung Vibrant phone)! App Inventor is intriguing, and I like its goal of making software development more accessible to a larger pool of potential app-developers. In terms of "visualizing information", App Inventor (and the Open Blocks library which it uses) does a great job of making it easy to see the programming constructs ("when...do...set") which make up a program, and I can see it being helpful to the novice app developer. It'll be interesting to see what interesting/complex apps are actually built using App Inventor. I think some key metrics of success for a tool like App Inventor are: 1) how many novice software developers use it as a gateway tool to build their initial Android apps, and then move on to more advanced Android programming (without using App Inventor); and 2) how many truly rich and interesting interactive applications are built using App Inventor. Only time will tell if this catches on. That said, I suspect that this tool may find use with casual tinkerers, but at least in its current state, it probably lacks the horsepower to really be part of a serious Android developer's toolbox: http://www.zdnet.com/blog/sybase/googles-app-inventor-for-android-the-wrong-bet-for-serious-mobile-enterprises/314 It's interesting that Yahoo also is experimenting with visual programming as well. http://pipes.yahoo.com/pipes/ Beykin, thanks always, for your consistent support of this project, it means a lot.

Funny timing, you posted this link the very day before I picked up my first Android phone (a Samsung Vibrant phone)!

App Inventor is intriguing, and I like its goal of making software development more accessible to a larger pool of potential app-developers. In terms of “visualizing information”, App Inventor (and the Open Blocks library which it uses) does a great job of making it easy to see the programming constructs (“when…do…set”) which make up a program, and I can see it being helpful to the novice app developer. It’ll be interesting to see what interesting/complex apps are actually built using App Inventor.

I think some key metrics of success for a tool like App Inventor are: 1) how many novice software developers use it as a gateway tool to build their initial Android apps, and then move on to more advanced Android programming (without using App Inventor); and 2) how many truly rich and interesting interactive applications are built using App Inventor. Only time will tell if this catches on. That said, I suspect that this tool may find use with casual tinkerers, but at least in its current state, it probably lacks the horsepower to really be part of a serious Android developer’s toolbox: http://www.zdnet.com/blog/sybase/googles-app-inventor-for-android-the-wrong-bet-for-serious-mobile-enterprises/314

It’s interesting that Yahoo also is experimenting with visual programming as well. http://pipes.yahoo.com/pipes/

]]> Comment on Inspiration for the weekend #4 by Beckham http://blog.kineticdiagrams.com/2010/07/09/inspiration-for-the-weekend-4/comment-page-1/#comment-36 Beckham Tue, 13 Jul 2010 00:39:23 +0000 http://blog.kineticdiagrams.com/?p=81#comment-36 I thought this idea would be helpful in your thought process in terms of shedding light from a different angle on your journey to bringing Kinetic Diagrams to life. So, wanted to share it. Here it is: http://appinventor.googlelabs.com/about/ The concept of "visualizing information" is utilized brilliantly for design purposes in this project. Keep up the good posts Jim! Enjoy reading it. I thought this idea would be helpful in your thought process in terms of shedding light from a different angle on your journey to bringing Kinetic Diagrams to life. So, wanted to share it. Here it is:

http://appinventor.googlelabs.com/about/

The concept of “visualizing information” is utilized brilliantly for design purposes in this project.

Keep up the good posts Jim!

Enjoy reading it.

]]> Comment on Think “ground” not “figure” by Furqan http://blog.kineticdiagrams.com/2010/06/06/focus-on-ground-not-figure/comment-page-1/#comment-11 Furqan Tue, 15 Jun 2010 00:45:01 +0000 http://www.kineticdiagrams.com/blog/?p=4#comment-11 Hi Jim, Great "first" entry! Happy to have played a small role in your light bulb moment. When engineers focus on the interfaces also it almost forces them to gain an understanding of the bigger picture, to understand the functional or business purpose of the software they are developing. Better collaboration with team members AND improved customer interaction are byproducts of that mindset. Look forward to reading additional thoughts on this subject on your blog! Best, Furqan Hi Jim,

Great “first” entry! Happy to have played a small role in your light bulb moment. When engineers focus on the interfaces also it almost forces them to gain an understanding of the bigger picture, to understand the functional or business purpose of the software they are developing. Better collaboration with team members AND improved customer interaction are byproducts of that mindset.

Look forward to reading additional thoughts on this subject on your blog!

Best,

Furqan

]]> Comment on My sketchy purchase: a Wacom Bamboo by Cara http://blog.kineticdiagrams.com/2010/06/11/my-sketchy-purchase-a-wacom-bamboo/comment-page-1/#comment-10 Cara Sat, 12 Jun 2010 06:39:52 +0000 http://blog.kineticdiagrams.com/?p=28#comment-10 i am excited to see your whiteboard come to life on your blog! i am excited to see your whiteboard come to life on your blog!

]]> Comment on Ragel rocks (part 1 of 2) by Jim Tran http://blog.kineticdiagrams.com/2010/06/08/ragel-rocks/comment-page-1/#comment-9 Jim Tran Wed, 09 Jun 2010 17:33:58 +0000 http://blog.kineticdiagrams.com/?p=11#comment-9 I think the vernacular of the field ("finite state automata" and "BNF") can be a bit off-putting to those who want to dabble in language parsing. There's a tremendous amount of mathematical rigor behind language parsing theory; unfortunately, the downside of that is that it makes it appear less accessible than it really is. Which is a shame, because as Zac hints at, there are many *interesting* problems where a custom DSL can form the groundwork for a robust solution. I think the vernacular of the field (“finite state automata” and “BNF”) can be a bit off-putting to those who want to dabble in language parsing. There’s a tremendous amount of mathematical rigor behind language parsing theory; unfortunately, the downside of that is that it makes it appear less accessible than it really is. Which is a shame, because as Zac hints at, there are many *interesting* problems where a custom DSL can form the groundwork for a robust solution.

]]> Comment on Ragel rocks (part 1 of 2) by Josh http://blog.kineticdiagrams.com/2010/06/08/ragel-rocks/comment-page-1/#comment-7 Josh Tue, 08 Jun 2010 20:31:49 +0000 http://blog.kineticdiagrams.com/?p=11#comment-7 I too never took that class (I don't understand why it wasn't required at my school... seems like it should have been). Because of that, I have found it very difficult any time I have attempted to use javacc and the like to create parsers. Regexes seem quite a bit more useful when that's all you have :) I too never took that class (I don’t understand why it wasn’t required at my school… seems like it should have been).

Because of that, I have found it very difficult any time I have attempted to use javacc and the like to create parsers.

Regexes seem quite a bit more useful when that’s all you have :)

]]> Comment on Think “ground” not “figure” by Josh http://blog.kineticdiagrams.com/2010/06/06/focus-on-ground-not-figure/comment-page-1/#comment-6 Josh Tue, 08 Jun 2010 20:30:00 +0000 http://www.kineticdiagrams.com/blog/?p=4#comment-6 I have a lot of //TODO's in my code, I'm ashamed to say. I have a lot of //TODO’s in my code, I’m ashamed to say.

]]> Comment on Ragel rocks (part 1 of 2) by Zac http://blog.kineticdiagrams.com/2010/06/08/ragel-rocks/comment-page-1/#comment-5 Zac Tue, 08 Jun 2010 17:09:39 +0000 http://blog.kineticdiagrams.com/?p=11#comment-5 I never took the compiler course at my university--though I purchased the books and had signed up one Spring semester before deciding to drop. That said, this whole post puts me in mind of FSAs and state machines and all sorts of stuff that I knew once upon a time, but would be hard pressed to do nowadays. These are actually the *interesting* problems to solve, as opposed to most of what we do as professional programmers (i.e. make that button be higher up, etc). Long story short, this post just made me realize how stupid I am. Ah well. C'est la vie. I never took the compiler course at my university–though I purchased the books and had signed up one Spring semester before deciding to drop. That said, this whole post puts me in mind of FSAs and state machines and all sorts of stuff that I knew once upon a time, but would be hard pressed to do nowadays.

These are actually the *interesting* problems to solve, as opposed to most of what we do as professional programmers (i.e. make that button be higher up, etc).

Long story short, this post just made me realize how stupid I am. Ah well. C’est la vie.

]]> Comment on Think “ground” not “figure” by Jim Tran http://blog.kineticdiagrams.com/2010/06/06/focus-on-ground-not-figure/comment-page-1/#comment-4 Jim Tran Tue, 08 Jun 2010 04:15:39 +0000 http://www.kineticdiagrams.com/blog/?p=4#comment-4 Zac, thanks for the incisive points. I agree design should be iterative as well, and should emerge alongside the code. As you point out, the appropriate interface definitions may only emerge after several sessions of indiscriminate code-bashing. For many projects, coding and design tasks are necessarily intertwined. The behavior I observe too often, however, is this: in the rush to deliver, the interface definitions becomes "frozen" too soon after the "get something working first" milestones are reached. As soon as the code works, it's tempting for developers to move on, without taking the time to perform the requisite code refactoring needed to clean up the functional interfaces. Within a class, this means cleaning up method signatures, and tuning the public/private visibility of methods. Between sub-systems, the externally-visible API contracts need to be re-visited. This refactoring to clarify the functional interfaces isn't particularly fun. Really, who enjoys paying off debt? The Kinetic architecture diagram evolved alongside several weeks of Ruby coding. I need to now practice what I preach, and spend some time to *really* think about the functional interfaces between the various Kinetic sub-systems. I'll choose to pay those debts now. When it comes to clarifying functional interfaces, as John Wooden said, "If you don't have time to do it right, when will you have time to do it over?" Zac, thanks for the incisive points.

I agree design should be iterative as well, and should emerge alongside the code. As you point out, the appropriate interface definitions may only emerge after several sessions of indiscriminate code-bashing. For many projects, coding and design tasks are necessarily intertwined.

The behavior I observe too often, however, is this: in the rush to deliver, the interface definitions becomes “frozen” too soon after the “get something working first” milestones are reached. As soon as the code works, it’s tempting for developers to move on, without taking the time to perform the requisite code refactoring needed to clean up the functional interfaces. Within a class, this means cleaning up method signatures, and tuning the public/private visibility of methods. Between sub-systems, the externally-visible API contracts need to be re-visited. This refactoring to clarify the functional interfaces isn’t particularly fun. Really, who enjoys paying off debt?

The Kinetic architecture diagram evolved alongside several weeks of Ruby coding. I need to now practice what I preach, and spend some time to *really* think about the functional interfaces between the various Kinetic sub-systems. I’ll choose to pay those debts now.

When it comes to clarifying functional interfaces, as John Wooden said, “If you don’t have time to do it right, when will you have time to do it over?”

]]> Comment on Think “ground” not “figure” by Zac http://blog.kineticdiagrams.com/2010/06/06/focus-on-ground-not-figure/comment-page-1/#comment-3 Zac Mon, 07 Jun 2010 19:29:36 +0000 http://www.kineticdiagrams.com/blog/?p=4#comment-3 Interesting point and I think a valid one. The more common problem in my opinion, though, is not a focus on one aspect of a design versus another (i.e. interfaces versus components) but the focus on design period--at least insofar as it being a discrete phase. In fact, what you're saying is pretty concordant with the formal computer science education I received and the notion of waterfall design where the contracts between components have to be solid, wherease the implementation can be worked out later. I think this approach raises the notion of 'design' to too lofty a place in the software lifecycle, though. By that I mean, a focus on interfaces is important, and as you point out, probably one of the most important aspects of design. But I think it should emerge as the system takes shape. Get something working first, have good unit tests, then iterate on the interface and think about how it does or doesn't make sense for the problems you're actively trying to solve, not ones you may have one day, if so-and-so just happens to need to do X. Interesting point and I think a valid one. The more common problem in my opinion, though, is not a focus on one aspect of a design versus another (i.e. interfaces versus components) but the focus on design period–at least insofar as it being a discrete phase. In fact, what you’re saying is pretty concordant with the formal computer science education I received and the notion of waterfall design where the contracts between components have to be solid, wherease the implementation can be worked out later. I think this approach raises the notion of ‘design’ to too lofty a place in the software lifecycle, though. By that I mean, a focus on interfaces is important, and as you point out, probably one of the most important aspects of design. But I think it should emerge as the system takes shape. Get something working first, have good unit tests, then iterate on the interface and think about how it does or doesn’t make sense for the problems you’re actively trying to solve, not ones you may have one day, if so-and-so just happens to need to do X.

]]>