You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Kurogo, Open Source, and Foot in Mouth

January 13, 2015 — JaZahn

Several years ago I worked on a mobile project using modo labs’ kurogo. What we did was simple enough. It provided a mobile framework, using its own phonegap-like technology as a way to “compile” we code into native apps for android and ios. When we were a decade behind in mobility, it provided a means to do things that sounded like they should be done.

Fast forward to present. Modo labs is touting their new v2.0. That’s interesting, right? I knew their 1.x platform and was not impressed, but this is new. In the wake of the new rages in mobility (spa’s and APIs) I couldn’t wait to see what they had come up with.

But wait I did. It took several months to provide me with code to muck with. A project that really enjoys calling itself open source — but they’re not making v2.0 open source. That’s the secret sauce. Okay, fine, maybe they’re having trouble making money with an open source project. I shouldn’t judge it too harshly on that.

Well, I finally got into some training on the product. Got my hands on the code literally 20 minutes before the training. The setup docs were poorly written. In a time where vagrant and docker are on my mind a lot, not having a VM, having to set things up manually seemed like taking a step backwards in time.

Finally got into the nitty gritty, and quickly noticed not much had changed. They are still peddling the same design decisions they made a decade ago. A new enhanced administration, but the apps being created will look pretty much the same. The configuration files write the application for you. As a developer, this was disappointing.

But I realized they’re not making a product for developers. They’re creating a product for configuration managers.

I was floored when I saw PeopleSoft “development” for the first time. It’s the future though. It’s a way to create applications without having to pay for developers with specialized education / experience.

As the people who are putting together the University’s PeopleSoft campus solution I’m sure will tell you, it’s a double edged sword. A LOT can be done by people with minimal training, but getting outside of the box, creating “experiences” becomes borderline impossible.

That said, Kurogo I’m sure has its place among a certain breed of application. And I hope it will take off, and people find use for it. But it is an elegant product, for a more civilized age.

Posted in Uncategorized. Tags: , . Comments Off on Kurogo, Open Source, and Foot in Mouth »

Jira vs Github :: Agile vs Open Source

September 21, 2014 — JaZahn

A few years ago, my team got into Open Source. Specifically, we started writing all of our apps on github (as opposed to our SVN). We wanted to do this because we wanted to invite scrutiny. We never expected people to look at our stuff, we just felt that by putting it out in the open, we’d want to do better internally.

We went whole-hog. Organized stories with issues, organized sprints with milestones. It was pretty hot stuff. And it was all in the open. Potentially, someone could come by, see what we’re doing and offer to take a story from the backlog of issues. That’s open source. ish. We have a lot more we can do. A lot of growth to do.

Then we started using Jira. The board system within Jira Agile was excellent. Allowed for better organization, reporting!, and visual representations of work. It’s great. It’s Agile. But it also replaced what we were doing with Github issues.

We essentially replaced Open Source in favor of Agile. Our organization is great, we’re keeping track of things fantastically, but we’re no longer open. We don’t have transparency on what we’re working on anymore. People can’t potentially help. Our code is out there, but we’re not inviting. Our process is no longer out there.

So what’s our solution? We don’t have one yet. But what /can/ we do?

We need to put our vision statement out there. We need to put our plans out there. We need to expose what it is we’re doing. We also need to stay agile, keep our tools intact, keep our reporting.

This means we probably need to be duplicating efforts. Open Source and Agile are both hard work and organization. That they can’t line up and be the same effort is not a blocker, just an “oh well”.

Posted in Agile, ATG, Git, Open Source, SVN. Tags: , , , . Comments Off on Jira vs Github :: Agile vs Open Source »

Version Control and Sensitive Data

October 2, 2013 — JaZahn

Don’t put passwords in your repositories.

 

https://help.github.com/articles/remove-sensitive-data

Posted in Uncategorized. Tags: , , . Comments Off on Version Control and Sensitive Data »

Continuous Integration with PHP on Travis CI and Github

March 21, 2013 — JaZahn

People on high have been preaching the wonder of continuous integration for a while now. It’s been all about Jenkins forever. Jenkins is still the #1 choice for most people, but I recently ran into Travis CI and at least short term, this is going to be the solution for our shop.

What is Continuous Integration for PHP?

CI to most people involves building and running integration tests. PHP clearly doesn’t build, but good PHP still has unit tests / integration tests / functional tests — so CI for PHP is running those tests before code merges.

What makes Travis CI good?

Probably ease of use. There is no setup of a “travis server”. It’s a service that they run. You hook it to a repo you have access to and set up a config file and it’s good to go.

But this only works with github?

That’s probably the biggest detractor. It’s currently built exclusively for use with github. Which is awesome for github projects, but not every project can be on github. We don’t always have control over where our repos are — and not everyone is an open source person.

Posted in Development, Open Source, PHP. Tags: , , , , , . Comments Off on Continuous Integration with PHP on Travis CI and Github »

Deciding on a Style Guide

December 15, 2012 — JaZahn

Recently a couple of groups here at work were brought together to try and standardize on a few things. The Software Development Community of Practice! Style guides came up. Everyone said they had no style guide and everyone agreed having a style guide would be worthwhile.

I had spent some time writing a style guide (customizing) so I was interested by this. I got to reflect on my style guide, how I’ve referred back to it in the year since I put it out there, and how I think it has helped or could help in this forum.

See the reason I created this style guide is not all that different from the reason these communities of practice are looking to create style guides. I was/am writing open source, and on the hope that someone will want to contribute to the project, I want a rule set defined so people won’t submit something unreadable.

For the community of practice, it’s a little different, but the spirit is the same. What they want is to have the option to point at something when a fellow developer is writing horrible code. The premise is you have a new developer and they don’t know how to write clean code.

The problem I have with this is everyone knows how to write clean code. And by everyone, I mean every professional software developer. If they’re not writing clean code, they’re not professional. Now that of course means if we are using student employees or taking in work from unknown outsiders (Open Source), that we are risking poorly written code being introduced and should therefore have a style guide. But if the premise is to have something for professional developers, I think it’s a waste of time.

Most style guides are 95% the same and we’re not talking about trying to enforce the 5% that is going to be different between individual developers. If ever a problem comes up with software developers where one is trying to say another’s code style is wrong, they should be able to say “google a style guide to see what best practices are” and be done with it.

Sadly, I’ve wasted more time arguing this than it would have taken to just agree, pick a guide that no one will ever use and move on.

Posted in Development, Open Source. Tags: , , . Comments Off on Deciding on a Style Guide »

A little bit of Agile, a dash of Open Source, and a pinch of ITIL

October 30, 2012 — Michael D. Hilborn
Agile, Open Source, and ITIL

From left to right: Agile, ITIL, and Open Source: An (un)holy trinity?

So I’ve hopefully started what will become a multi-part series about integrating Agile, Open Source, and ITIL into an overall strategy for delivering web services. You can find the first part on my personal web site. WARNING:  The first post is simply a high, very high, overview of the three methodologies, so you may find nothing new in there.  Indeed, here’s a snippet speaking to that very fact:

First, an admission: Open Source, Agile, and ITIL are nothing new to the realm of IT; all have been around for years, if not decades, and many industries have embraced them in some form or another. So the fact we are now incorporating these practices into our work might not seem exactly novel and, if I was strictly speaking about incorporating just the individual practices into our work, such an assertion would be correct. But I’m talking about merging all three, and a quick Google Search on “implementing,” “incorporating,” “combining” or “merging” this trinity doesn’t exactly return a cornucopia of results. So maybe what were doing is somewhat novel, after all.

Posted in Agile, Development, ITIL, Open Source. Tags: , , , . Comments Off on A little bit of Agile, a dash of Open Source, and a pinch of ITIL »

Github zip doesn’t include Submodules

October 18, 2012 — JaZahn

Seriously, what were they thinking. This completely invalidates the use of submodules. We want our code to be available without having to know git. That’s the whole reason they have the download a zip link. But not including all of the code means you have to unzip the code and then use git to get the submodules.

Submodules are great for code reuse. But if I can’t intend my project to be downloaded by people that just want to install it and not code anything while using submodules. This is horrible.

Posted in ATG, Git, Quizmo, Version Control. Tags: , , , , , . 3 Comments »

Inserting images into Github’s wiki

October 2, 2012 — JaZahn

This is something I was not able to find clear information on. Specifically, I wanted to add a flow chart I’d created to the wiki. I’ll also be adding an ER diagram later. It’s cool to have the important development documents somewhere where they can be accessed and perhaps edited from anywhere by anyone if need be. Github has a failing in this regard I think. They should have an interface for this.

The trick of it all is the wiki is itself a git repo. What you have to do is check out that repo. In my case, my project was https://github.com/jazahn/HarvardCards. To checkout that project, you would use the command:


clone git@github.com:jazahn/HarvardCards.git .

But that’s the project. The wiki is:

clone git@github.com:jazahn/HarvardCards.wiki.git .

So you have to check that out, add the image file to it, and then you can [[add the image]] via relative path image link. https://github.com/jazahn/HarvardCards/wiki/Flashcard-Flowchart

Posted in ATG, Flashcards, Git, Version Control. Tags: , , , . Comments Off on Inserting images into Github’s wiki »

Open Sourcing Now vs Later

September 13, 2012 — JaZahn

We decided a little while ago to open source our projects. We had people asking for it and we kept having to say “sorry, we can’t really do that”. Our software wasn’t written with the understanding that anyone would look at it ever, so like most software it was poorly documented and tightly coupled with proprietary services. So it wouldn’t really be helpful to people and we were embarrassed by our own code (as most people are).

So we decided to rewrite some of our applications and the question came up should we open source it from line one of the code or wait until we were at version 1.0. When talk first started about open sourcing everyone agreed open sourcing from line one was the way to go. We three it out on github and just worked off of that. Then people started asking to see it. And there was some delay because we needed to decide on a license. And then we had a license and no one wanted to release.

I personally wanted to tell people where the code was. That’s the point I thought. But it became increasingly important to everyone else to release a more complete project. The thinking, I believe, is that if we release something that isn’t really useful to anyone from the get go, people aren’t going to ever check back. The thinking is they’ll take one look, say “huh” and never look back.

I can understand that but I still don’t agree with it. If you wait to open source software until it’s in a state you feel comfortable with, it will just keep getting pushed back because we as developers often have a perfectionist complex. It will never be perfect though.

The solution, I believe, is documentation. Not developer documentation, but very simple user documentation that doesn’t take long to read that they can look at and get a good idea at the state of the project and he direction of the project. A properly organized issue list can be very helpful. If peole can take a look at what’s being worked on, they can get a feel for where the project is. Thankfully github facilitates all of this in one place.

Just put it out there, but make it easily understandable what he state of the project is, where it works and where it’s lacking.

Posted in ATG. Tags: , . Comments Off on Open Sourcing Now vs Later »

Github Pull Request for Just One Commit

July 10, 2012 — JaZahn

I have a forked Yii which I use as a submodule in a couple of my applications. I haven’t made many changes, but most would probably not be useful most people. i.e. I put a conditional in that checks the version of PHPUnit and if it’s older than 3.5 it uses a different include file. Thereby letting me get around the limitation I have in one of my development environments.

My last commit, however, directly relates to an issue Yii had identified. So I wanted to push only that last commit upstream.

First make sure you have the upstream remote.
Then fetch from upstream — this creates upstream/master.
Then we create a new branch calling it upstream — not to be confused with the local remote we just created with the same name.


cd yii
git remote add upstream git://github.com/yiisoft/yii.git
git fetch upstream
git checkout -b upstream upstream/master
git cherry-pick
git push origin upstream

Then use something that was new to me, cherry-pick and give it the hash of the specific commit. That will merge over only that commit to the new branch you made. Then just push it.

From github, you can then make a Pull Request from that specific branch and contribute. Since that’s what it’s all about.

Helpful links:
https://help.github.com/articles/fork-a-repo
http://kurogo.org/guide/github.html
http://stackoverflow.com/questions/5256021/send-a-pull-request-on-github-for-only-latest-commit

Posted in ATG, Git, Quizmo, Version Control, Yii. Tags: , , , . 2 Comments »
« Older posts «
»