Skip to main content

Querying GitHub Issues from Google App Script

I'm currently exploring different integrations that can be done between Google App Script and Git. This is part of a bigger attempt to integrate Git data into my project management system. I'll post more on that later. GitHub supports a number of very nice sub-systems. One of them is the GitHub Issues ticket tracking system. It's fairly robust and comes with GitHub - which means it's highly integrated out-of-the-box. Integration with Google's App Script is done via the fetchURL command and JSON object manipulation.  After a good bit of experimentation, I've settled on querying GitHub Issues with an "on open spreadsheet event" to avoid issues with Google's quota system. Essentially, Google prevents you from calling the fetchURL command more than X times (see the quota limits ) per day. That's not great if you have people actively working and changing data in a spreadsheet. Some of my other App Script routines are running thousands of times per d...
Post a Comment

Qt becomes LGPL licensed

Nokia has announced that the new Qt library (4.5) will be available under the LGPL license (March 2009). Hopefully, this will mean that Embarcadero will revive Linux support with it's upcoming 64-bit, compile-to-many-targets compiler rewrite.

Actually, it could mean that we would finally have a true CLX revision that would let us have native write-once, compile-to-many-targets, cross platform support for Windows, Mac, Linux, Embedded Linux, Windows CE, and the S60 (eventually). If Delphi's component architecture could be revamped to produce true Qt widgets, Embarcadero would suddenly enable all of the Delphi component vendors to gain access to a client-base that is much larger than what Delphi currently offers. Qt does not have much selection from third-party component vendors. A DevExpress or TMS Software offering would provide a nice upgrade to the basic Qt widgets.

Delphi Prism theoretically supports multi-platform through the use of Mono but you have to add the managed code overhead to everything. There was a recent article on using Mono to develop for the iPhone which talked about stripping the managed code down to a true compiled state (Apple doesn't permit managed code to run apparently.) It was done with C# but there is no particular reason (that I'm aware of) Delphi Prism couldn't work the same way. Has anyone tried to do multi-platform with Prism?
Labels:

Comments

Anonymous said…
That is really cool new. QT was always kind of an odd duck because it wasn't LGPL licensed.
January 14, 2009 at 12:59 PM
Anonymous said…
I don't think many developers understand the LGPL, so I hope my comment helps.

NOTE: Before attacking this comment, please do 2 things:

1. read the LGPL
2. ask FSF.ORG if they disagree with my comments

The LGPL allows you to license your derived works under your own terms, but only if your own terms allow reverse-engineering, among other things.

E.g., if your commercial software links to an LGPL library, then your software's EULA cannot forbid users from reverse-engineering your software.

Too many developers assume LGPL means "anything goes" and they end up violating the terms.

This is why many LGPL libraries include an "escape clause" for software that links to unmodified versions of the library. Unless QT provides such an escape clause to LGPL, I'm forbidden by my company to use it.
January 14, 2009 at 2:36 PM
Anonymous said…
forbidden by your company to use it? You can still pay for that right from Nokia if you really want it. Nobody is forcing you to use the LGPL. Pay for the right to use it how you want. Or don't complain if its free. Honestly some people.
January 15, 2009 at 2:25 AM
Anonymous said…
2Anonymous
>I don't think many developers understand the LGPL

I think that YOU do not understand the LGPL. And YOU should read LGPL again and again and again...
January 15, 2009 at 5:55 AM
Marshall Fryman said…
LGPL does have a reverse engineering provision; however, please read the FSF.org definition closely: "allow new versions of the library to be linked with the application; and allow reverse engineering to debug this." Place the emphasis on debug and you can see how this is not, in my opinion, a major issue.

For the record, the likely hood of finding someone who is technically competent enough to reverse engineer your program AND malicious in intent is probably vanishingly small. So long as you are maintaining the software, 99.9% of people will simply contact you and ask for a fix. If you aren't maintaining the software (and most likely not generating revenue from it as a result), what difference does it make if someone patches it for you?
January 15, 2009 at 9:31 AM
Unknown said…
@multiple anoyamouses
Why do you people have to post as anonymous?

I do not want particularly to know your real names, but it is much easier to remember who explained what if you use a sensible pseudonym. Please get a login name.

Doei Rif
January 15, 2009 at 12:46 PM
Anonymous said…
The 1st comment by me (Anonymous) is NOT a criticism of LGPL. And it was NOT a criticism of QT being license under LGPL.

I was trying to help others avoid violating the terms of LGPL out of misunderstanding or willful ignorance.

Let us separate facts from opinions.

FACTS:

1. I contacted FSF.ORG about LGPL and got confirmation about my understanding. If you disagree with my understanding, email them yourself.

2. Many LGPL libraries--run by smarter people than I--provide exceptions that address the exact issue I raised (what I called "escape clause" in my 1st comment).

Since this is about QT being released under LGPL, I will provide two examples of GUI libraries that are licensed under LGPL + "escape clause":

http://www.wxwidgets.org/about/licence3.txt

http://www.fltk.org/COPYING.php

Why would they bother including exceptions to LGPL to address issues unless it was real?

If your understanding of LGPL differs from mine, contact FSF.ORG or a qualified intellectual property attorney instead of being offended.

Frankly, I don't understand why some people get upset over this when it is much more practical to get facts from qualified people.

Just because someone offers an interpretation of LGPL that is different from yours doesn't mean they are automatically wrong, and it isn't rational to get upset about it. Wishing something to be true isn't the same as it being true.

If you want to enjoy the fruits of labor provided by the generous folks creating LGPL libraries, please comply with their license.
January 17, 2009 at 9:24 AM
Post a Comment

Popular posts from this blog

SMTP Mail and Indy (again)

Having spent a lot of time recently working on a ping scanner using Indy, I noticed that there's a lot of questions still on using SMTP with Indy. Let me first say that I am not an Indy expert. I get along with it successfully but find I still have to research things frequently. With the disclaimer out of the way, we can get to the offering. A while back I wrote a handy little unit to simply send a mail message with or without attachments and with or without providing authentication. It even has support for OpenSSL. I use this unit in a number of applications and have seen it successfully send hundreds of e-mails without issue. I recently added support for threaded message sending to take advantage of the multi-core system I'm now running on. This code has had a few additions (like the logger) that I've gleaned over time from various newsgroup postings, but I didn't record the authors so let me credit the anonymous Internet authors who support Indy. It's really amaz...
14 comments
Read more

Detecting a virtualized environment

CubicDesign on delphi-talk.elists.org recently asked the question: "How do I know/detect if my software is running under Windows [or a virtual environment]?" Well, it turns out that it's a lot harder to tell than you would think. Apparently, the VM (VMware, Xen, Wine, etc.) doesn't really want you to be able to do this. At least not easily. For VMware, there is a decent little C routine called jerry.c that does the trick. Jerry actually uses a simple communication channel that VMware left open. It's not 100% foolproof since the admin can change the channel, but that's not likely going to happen unless the system is specifically designed to be a honeypot. If you're running on a honeypot and still have a legitimate reason for detection, you could look at the much more complex scoopy implementation which inspects how the system is actually virtualized using the SIDT CPU instruction instead of a communication channel. Another reference (red pill) is here . F...
6 comments
Read more

Delphi Case with Strings

Zarko Gajic posted about this topic on his Delphi Tips recently showing how one could use a case statement with strings. His solution basically passes in an array on the stack and then iterates through it providing the index number of the matching string. I don't often want to do this, but the idea comes up occassionally enough that I thought I'd play with it a little. The first thing that struck me with this is that passing things on the stack is bound to be slow. Any time you can avoid memory allocation in your routines, do it. The way Zarko wrote his StringToCaseSelect routine created a COPY of the information on the stack. In my testing, just changing the CaseList: array of string to CaseList:const array of string improved the performance of the code by almost 30% for his example. Mind, I'm not using hyper-precise counters; however, it definitely makes a difference. Secondly, I was curious how the performance changed if I used the old stand-by: If then else. Using the ...
10 comments
Read more

Copyright 2008-2022, Marshall Fryman