I don't know much about this, just randomly stumbled across these docs just
now.
But I do know that PHPFog has been a common ThinkUp hosting suggestion for
a while.
Will try to dig up a blog post or something later unless someone gets there
first.
Our contact at PHPFog spun off a side business that launches webapps
like ThinkUp on AppFog (which is superseding PHPFog). Here's the TU
launcher he just put together:
Anyone have the time to test it out and let us know how it goes? If
it's a reliable launcher, we'll update our docs to point to it instead
of the PHPFog jumpstart, which is going away.
> I don't know much about this, just randomly stumbled across these docs just
> now.
> But I do know that PHPFog has been a common ThinkUp hosting suggestion for a
> while.
> Will try to dig up a blog post or something later unless someone gets there
> first.
I tried launcher.io out tonight, and at least as far as ThinkUp, it's
just not ready for promotion. Getting the ThinkUp application
installed at a base level is simple enough, but things just get weird
once you actually try to use it.
--1--
Creating the Twitter app, consumer keys and whatnot, is fine.
But I can't get the application to authenticate a Twitter account normally.
ThinkUp ends up at a URL like http://thinkup-#####.aws.af.cm (Where
##### is some generated block of numbers; I did a few installs.) I
hadn't noticed at first, but on the TU Twitter settings page, all of
the provided URLs for app setup(callback, etc) are in the form
http://thinkup-#####.aws.af.cm:43851/ I have no idea where that port
number is coming from; neither Launcher nor AppFog ever display it,
that I've seen. Once you log in at Twitter and allow TU access to your
account, the redirect back ends up timing out.
Figuring the mystery port was the problem, I created a new Twitter app
without the port at all, and the timeout error /still/ wound up there.
But if you let the error occur, strip the port off, and re-submit the
clean URL, authentication goes through immediately.
I'm not even sure if this is a problem for Launcher or AppFog to address.
--2--
Launcher transparently creates a ThinkUp account for you. This is
understandable considering it's part of the installation process, but
when you pull it apart, it's /really/ weird and confusing:
* Keep in mind this is all happening under a heading that says "Launch ThinkUp."
* To start the installation process, you're asked to provide an
email/password combination.
* Those credentials are used to either log you in to, or create an
account for you at AppFog, as needed.
* During ThinkUp installation, an account is created using the e-mail
address provided, but NOT the password. (I assume. I used the same
e-mail address for my launcher.io account as for the AppFog one, so
maybe it's coming from there?)
* Once that's finished, you get a link for visiting your new ThinkUp
installation, which you can't log into because you have no idea what
your password is.
* Now you have to go through the "forgot" process to request a reset,
check your e-mail, go back to TU, manually change the password, and
THEN log in, by which point any reasonable person is probably getting
irritated.
Nerds might grumble through this, but if launcher.io is something
that's going to be suggested to people less knowledgeable, what's
going on in this process needs to be clearly documented. (Never mind
the port/auth thing above.)
Ideally, it would actually ask what you want your TU credentials to
be, but I don't know how flexible the launcher installer system is for
adding that sort of thing. I see the obvious argument for not just
reusing the provided password. If we're honest, though, a lot of
people are going to do it anyway.
This seems to be a more general problem, for whatever it's worth. I
created a phpMyAdmin instance and never got into it because not only
are the PMA credentials…
---
$cfg['Servers'][$i]['user'] = $mysql_config["username"];
$cfg['Servers'][$i]['password'] = $mysql_config["password"];
(I obviously didn't configure MySQL, so WTH are those?)
---
…but it requires Basic auth and there's a *blank* htpasswd file
included making it doubly impossible without going through all the
command-line/repo/etc. stuff that Launcher seems intended to /avoid/.
I want to like this, but right now I'm honestly a bit unclear who it's
even for.
This is tremendously helpful, thank you Su. I've passed onto our
Launcher.io contact, and for now I'm going to hold off replacing the
links to the PHPFog jumpstart in the docs with this. Luckily we have
the EC2 launcher in the meantime.
On Sun, Nov 18, 2012 at 5:54 AM, Su <s...@generis.name> wrote:
> I tried launcher.io out tonight, and at least as far as ThinkUp, it's
> just not ready for promotion. Getting the ThinkUp application
> installed at a base level is simple enough, but things just get weird
> once you actually try to use it.
> --1--
> Creating the Twitter app, consumer keys and whatnot, is fine.
> But I can't get the application to authenticate a Twitter account normally.
> ThinkUp ends up at a URL like http://thinkup-#####.aws.af.cm (Where
> ##### is some generated block of numbers; I did a few installs.) I
> hadn't noticed at first, but on the TU Twitter settings page, all of
> the provided URLs for app setup(callback, etc) are in the form
> http://thinkup-#####.aws.af.cm:43851/ I have no idea where that port
> number is coming from; neither Launcher nor AppFog ever display it,
> that I've seen. Once you log in at Twitter and allow TU access to your
> account, the redirect back ends up timing out.
> Figuring the mystery port was the problem, I created a new Twitter app
> without the port at all, and the timeout error /still/ wound up there.
> But if you let the error occur, strip the port off, and re-submit the
> clean URL, authentication goes through immediately.
> I'm not even sure if this is a problem for Launcher or AppFog to address.
> --2--
> Launcher transparently creates a ThinkUp account for you. This is
> understandable considering it's part of the installation process, but
> when you pull it apart, it's /really/ weird and confusing:
> * Keep in mind this is all happening under a heading that says "Launch ThinkUp."
> * To start the installation process, you're asked to provide an
> email/password combination.
> * Those credentials are used to either log you in to, or create an
> account for you at AppFog, as needed.
> * During ThinkUp installation, an account is created using the e-mail
> address provided, but NOT the password. (I assume. I used the same
> e-mail address for my launcher.io account as for the AppFog one, so
> maybe it's coming from there?)
> * Once that's finished, you get a link for visiting your new ThinkUp
> installation, which you can't log into because you have no idea what
> your password is.
> * Now you have to go through the "forgot" process to request a reset,
> check your e-mail, go back to TU, manually change the password, and
> THEN log in, by which point any reasonable person is probably getting
> irritated.
> Nerds might grumble through this, but if launcher.io is something
> that's going to be suggested to people less knowledgeable, what's
> going on in this process needs to be clearly documented. (Never mind
> the port/auth thing above.)
> Ideally, it would actually ask what you want your TU credentials to
> be, but I don't know how flexible the launcher installer system is for
> adding that sort of thing. I see the obvious argument for not just
> reusing the provided password. If we're honest, though, a lot of
> people are going to do it anyway.
> This seems to be a more general problem, for whatever it's worth. I
> created a phpMyAdmin instance and never got into it because not only
> are the PMA credentials…
> ---
> $cfg['Servers'][$i]['user'] = $mysql_config["username"];
> $cfg['Servers'][$i]['password'] = $mysql_config["password"];
> (I obviously didn't configure MySQL, so WTH are those?)
> ---
> …but it requires Basic auth and there's a *blank* htpasswd file
> included making it doubly impossible without going through all the
> command-line/repo/etc. stuff that Launcher seems intended to /avoid/.
> I want to like this, but right now I'm honestly a bit unclear who it's
> even for.
Let's also note that at this point, people would be using Launcher.io
and seeing this at blog.appfog.com, which makes further references to
blog.cloudfoundry.com to explain what's going on, all while randomly
flipping between example code in Ruby, Node, and Java, plus some
references to Python and Celery.[1] (But never PHP.)
There's this docs page
https://docs.appfog.com/customize/task-scheduling which is more
focused, but to the point of terse.
[1] …and switching between the terms "cron jobs," "task scheduling,"
"background workers," and "background processing" more or less
interchangeably.
[I know I'm picking, but it again brings up the question of who this
will be put in front of.]
#1 is something I could use help with. This problem occurs because of a behavior in Cloud Foundry, so it isn't an issue with Launcher or AppFog, but the technology on which AppFog depends. This means it is an issue with any provider who uses Cloud Foundry. Here is the background. The application gets deployed to a multi-tenant server and each application gets a port number. All the instances are behind a load balancer which forwards requests from port 80 (on the load balancer), to the server/port running the application. ThinkUp uses the local port number with the assumption that it is it's external port number, but it isn't since all requests get forwarded from 80 to that port number. I need a way to tell ThinkUp to generate those URLs without the port number; how can I do that?
As a side note, please notice that the link to phpfog.com/thinkup is now broken. It redirects to a generic appfog.com page without a reference to ThinkUp. Obviously I would like to make ThinkUp work well on Launcher but it still requires work, so I totally understand that it isn't ready for prime time. However, because it is borked on phpfog.com I recommend removing the link from thinkupapp.com.
On Sunday, November 18, 2012 5:54:50 AM UTC-8, Su wrote:
> I tried launcher.io out tonight, and at least as far as ThinkUp, it's > just not ready for promotion. Getting the ThinkUp application > installed at a base level is simple enough, but things just get weird > once you actually try to use it.
> --1-- > Creating the Twitter app, consumer keys and whatnot, is fine. > But I can't get the application to authenticate a Twitter account > normally.
> ThinkUp ends up at a URL like http://thinkup-#####.aws.af.cm (Where > ##### is some generated block of numbers; I did a few installs.) I > hadn't noticed at first, but on the TU Twitter settings page, all of > the provided URLs for app setup(callback, etc) are in the form > http://thinkup-#####.aws.af.cm:43851/ I have no idea where that port > number is coming from; neither Launcher nor AppFog ever display it, > that I've seen. Once you log in at Twitter and allow TU access to your > account, the redirect back ends up timing out.
> Figuring the mystery port was the problem, I created a new Twitter app > without the port at all, and the timeout error /still/ wound up there.
> But if you let the error occur, strip the port off, and re-submit the > clean URL, authentication goes through immediately.
> I'm not even sure if this is a problem for Launcher or AppFog to address.
> --2-- > Launcher transparently creates a ThinkUp account for you. This is > understandable considering it's part of the installation process, but > when you pull it apart, it's /really/ weird and confusing:
> * Keep in mind this is all happening under a heading that says "Launch > ThinkUp." > * To start the installation process, you're asked to provide an > email/password combination. > * Those credentials are used to either log you in to, or create an > account for you at AppFog, as needed. > * During ThinkUp installation, an account is created using the e-mail > address provided, but NOT the password. (I assume. I used the same > e-mail address for my launcher.io account as for the AppFog one, so > maybe it's coming from there?) > * Once that's finished, you get a link for visiting your new ThinkUp > installation, which you can't log into because you have no idea what > your password is. > * Now you have to go through the "forgot" process to request a reset, > check your e-mail, go back to TU, manually change the password, and > THEN log in, by which point any reasonable person is probably getting > irritated.
> Nerds might grumble through this, but if launcher.io is something > that's going to be suggested to people less knowledgeable, what's > going on in this process needs to be clearly documented. (Never mind > the port/auth thing above.) > Ideally, it would actually ask what you want your TU credentials to > be, but I don't know how flexible the launcher installer system is for > adding that sort of thing. I see the obvious argument for not just > reusing the provided password. If we're honest, though, a lot of > people are going to do it anyway.
> This seems to be a more general problem, for whatever it's worth. I > created a phpMyAdmin instance and never got into it because not only > are the PMA credentials… > --- > $cfg['Servers'][$i]['user'] = $mysql_config["username"]; > $cfg['Servers'][$i]['password'] = $mysql_config["password"]; > (I obviously didn't configure MySQL, so WTH are those?) > --- > …but it requires Basic auth and there's a *blank* htpasswd file > included making it doubly impossible without going through all the > command-line/repo/etc. stuff that Launcher seems intended to /avoid/. > I want to like this, but right now I'm honestly a bit unclear who it's > even for.
> Let's also note that at this point, people would be using Launcher.io > and seeing this at blog.appfog.com, which makes further references to > blog.cloudfoundry.com to explain what's going on, all while randomly > flipping between example code in Ruby, Node, and Java, plus some > references to Python and Celery.[1] (But never PHP.) > There's this docs page > https://docs.appfog.com/customize/task-scheduling which is more > focused, but to the point of terse.
> [1] …and switching between the terms "cron jobs," "task scheduling," > "background workers," and "background processing" more or less > interchangeably.
> [I know I'm picking, but it again brings up the question of who this > will be put in front of.]
<mac...@skierkowski.com> wrote:
> Su,
> Can you explain how ThinkUp uses cron? The AppFog support team might be able
> to help you directly (supp...@appfog.com).
> On Thursday, November 22, 2012 11:09:34 AM UTC-8, Su wrote:
>> Let's also note that at this point, people would be using Launcher.io
>> and seeing this at blog.appfog.com, which makes further references to
>> blog.cloudfoundry.com to explain what's going on, all while randomly
>> flipping between example code in Ruby, Node, and Java, plus some
>> references to Python and Celery.[1] (But never PHP.)
>> There's this docs page
>> https://docs.appfog.com/customize/task-scheduling which is more
>> focused, but to the point of terse.
>> [1] …and switching between the terms "cron jobs," "task scheduling,"
>> "background workers," and "background processing" more or less
>> interchangeably.
>> [I know I'm picking, but it again brings up the question of who this
>> will be put in front of.]
On Fri, Dec 21, 2012 at 01:40:18PM -0800, Gina Trapani wrote:
> Right now the new AppFog jumpstart and Launcher.io options aren't
> working well enough to officially recommend them.
> Let me know if you have any questions,
Q: How can I help?
I'm interested in revisiting hosted ThinkUp, but the previous approach
wasn't workable so I have some different ideas about how to do it that
might not burn me out and deadlock the conflicting branches. ;^)
I think the best plan of attack here may be to pursue things that are loosely coupled to ThinkUp itself. What are tools or tech that could be automated or used to simplify people getting started.
The Amazon launcher was great in this regard in that it was totally separate from ThinkUp but super handy. Something I could see being worked on in a similar manner would be whatever tech is needed (scripts, config files, etc.) to simplify ThinkUp running on Cloud Foundry. That would let ThinkUp run on almost any cloud hosting provider.
Another project I've been very gung-ho about would be a WordPress bootstrapper that installs ThinkUp for anybody running wordpress.org. That's not a trivial project, but it is very doable.
Are those things along the line of what you're thinking about?
> I'm interested in revisiting hosted ThinkUp, but the previous approach
> wasn't workable so I have some different ideas about how to do it that
> might not burn me out and deadlock the conflicting branches. ;^)
Just noting that AppFog now can install ThinkUp for you. It's a streamlined process, but the emails could get stuck in your spam folder.
*Just in case activation email not sent:* 1) Deploy PHPMyAdmin using AppFog 2) Bind it to the database ThinkUp is running on 3) Set PMA_USERNAME to admin 4) Set PMA_PASSWORD to a password 5) Open PHPMyAdmin, login 6) Open the tu_owners tables 7) Change is_activated to 1
On Saturday, December 22, 2012 8:45:05 PM UTC-5, Anil Dash wrote:
> I think the best plan of attack here may be to pursue things that are > loosely coupled to ThinkUp itself. What are tools or tech that could be > automated or used to simplify people getting started.
> The Amazon launcher was great in this regard in that it was totally > separate from ThinkUp but super handy. Something I could see being worked > on in a similar manner would be whatever tech is needed (scripts, config > files, etc.) to simplify ThinkUp running on Cloud Foundry. That would let > ThinkUp run on almost any cloud hosting provider.
> Another project I've been very gung-ho about would be a WordPress > bootstrapper that installs ThinkUp for anybody running wordpress.org. > That's not a trivial project, but it is very doable.
> Are those things along the line of what you're thinking about?
> On Dec 21, 2012, at 5:03 PM, Trevor Bramble <in...@trevorbramble.com<javascript:>> > wrote:
> > Q: How can I help?
> > I'm interested in revisiting hosted ThinkUp, but the previous approach > > wasn't workable so I have some different ideas about how to do it that > > might not burn me out and deadlock the conflicting branches. ;^)
Basically, the previous attempt was a dead-end because the code changes
required to make it work were too pervasive to maintain while bringing
in changes from ThinkUp's master branch. (This was pre-1.0, of course.
Lots more churn.)
So to that end I think just being satisfied with the previous iteration
as a proof of concept and adding the modifications to TU as they're
built (in a non-hacky) way is the sane approach.
I think there will always be a need for hosted ThinkUp, even if it is
just the always-on buffered relay to someone's own local ThinkUp install
(on their smartphone, for example). Changing what constitutes the
ThinkUp application would change that perhaps. The moving-data-around
part of TU has always seemed quite separate from the web application,
for example.
For the ever-desired turnkey ThinkUp, there's Chef with either Vagrant
for local use or, I guess, a vSphere-compatible image for Cloud Foundry
hosts. I'm not sure why anyone would want to use a cloud hosting service
(ephemeral, usage-billed) rather than a regular VPS or the like.
I can't say I'd ever think of piggy-backing it on a WordPress install.
If I understand you correctly, that sounds like some dangerous coupling.
A clever hack, though.
* * *
I know the WordPress install has always been the golden ring here, but
perhaps the perfect, easy install scenario is only myth. Check out the
WP install docs: http://codex.wordpress.org/Installing_WordPress There
is hidden complexity in the Things to Know and Things You Need to Do
seconds, which you can see increasingly complicated instructions
branching from as you follow inline links and read through the rest of
the document.
It seems to me that ThinkUp has already met WordPress's example of
providing a usually-happy path, and did it a long time ago. It's just
never going to be without plenty of fringe scenarios that require
special handling by the TU user with or without community support.
On Sat, Dec 22, 2012 at 08:45:05PM -0500, Anil Dash wrote:
> I think the best plan of attack here may be to pursue things that are
> loosely coupled to ThinkUp itself. What are tools or tech that could
> be automated or used to simplify people getting started.
> The Amazon launcher was great in this regard in that it was totally
> separate from ThinkUp but super handy. Something I could see being
> worked on in a similar manner would be whatever tech is needed
> (scripts, config files, etc.) to simplify ThinkUp running on Cloud
> Foundry. That would let ThinkUp run on almost any cloud hosting
> provider.
> Another project I've been very gung-ho about would be a WordPress
> bootstrapper that installs ThinkUp for anybody running wordpress.org.
> That's not a trivial project, but it is very doable.
> Are those things along the line of what you're thinking about?
> On Dec 21, 2012, at 5:03 PM, Trevor Bramble <in...@trevorbramble.com> wrote:
> > Q: How can I help?
> > I'm interested in revisiting hosted ThinkUp, but the previous approach
> > wasn't workable so I have some different ideas about how to do it that
> > might not burn me out and deadlock the conflicting branches. ;^)
> #1 is something I could use help with. This problem occurs because of a
> behavior in Cloud Foundry, so it isn't an issue with Launcher or AppFog,
> but the technology on which AppFog depends. This means it is an issue with
> any provider who uses Cloud Foundry. Here is the background. The
> application gets deployed to a multi-tenant server and each application
> gets a port number. All the instances are behind a load balancer which
> forwards requests from port 80 (on the load balancer), to the server/port
> running the application. ThinkUp uses the local port number with the
> assumption that it is it's external port number, but it isn't since all
> requests get forwarded from 80 to that port number. I need a way to tell
> ThinkUp to generate those URLs without the port number; how can I do that?
> As a side note, please notice that the link to phpfog.com/thinkup is now
> broken. It redirects to a generic appfog.com page without a reference to
> ThinkUp. Obviously I would like to make ThinkUp work well on Launcher but
> it still requires work, so I totally understand that it isn't ready for
> prime time. However, because it is borked on phpfog.com I recommend
> removing the link from thinkupapp.com.
> On Sunday, November 18, 2012 5:54:50 AM UTC-8, Su wrote:
>> I tried launcher.io out tonight, and at least as far as ThinkUp, it's
>> just not ready for promotion. Getting the ThinkUp application
>> installed at a base level is simple enough, but things just get weird
>> once you actually try to use it.
>> --1--
>> Creating the Twitter app, consumer keys and whatnot, is fine.
>> But I can't get the application to authenticate a Twitter account
>> normally.
>> ThinkUp ends up at a URL like http://thinkup-#####.aws.af.cm (Where
>> ##### is some generated block of numbers; I did a few installs.) I
>> hadn't noticed at first, but on the TU Twitter settings page, all of
>> the provided URLs for app setup(callback, etc) are in the form
>> http://thinkup-#####.aws.af.**cm:43851/<http://thinkup-#%23%23%23%23.aws.af.cm:43851/>I have no idea where that port
>> number is coming from; neither Launcher nor AppFog ever display it,
>> that I've seen. Once you log in at Twitter and allow TU access to your
>> account, the redirect back ends up timing out.
>> Figuring the mystery port was the problem, I created a new Twitter app
>> without the port at all, and the timeout error /still/ wound up there.
>> But if you let the error occur, strip the port off, and re-submit the
>> clean URL, authentication goes through immediately.
>> I'm not even sure if this is a problem for Launcher or AppFog to address.
>> --2--
>> Launcher transparently creates a ThinkUp account for you. This is
>> understandable considering it's part of the installation process, but
>> when you pull it apart, it's /really/ weird and confusing:
>> * Keep in mind this is all happening under a heading that says "Launch
>> ThinkUp."
>> * To start the installation process, you're asked to provide an
>> email/password combination.
>> * Those credentials are used to either log you in to, or create an
>> account for you at AppFog, as needed.
>> * During ThinkUp installation, an account is created using the e-mail
>> address provided, but NOT the password. (I assume. I used the same
>> e-mail address for my launcher.io account as for the AppFog one, so
>> maybe it's coming from there?)
>> * Once that's finished, you get a link for visiting your new ThinkUp
>> installation, which you can't log into because you have no idea what
>> your password is.
>> * Now you have to go through the "forgot" process to request a reset,
>> check your e-mail, go back to TU, manually change the password, and
>> THEN log in, by which point any reasonable person is probably getting
>> irritated.
>> Nerds might grumble through this, but if launcher.io is something
>> that's going to be suggested to people less knowledgeable, what's
>> going on in this process needs to be clearly documented. (Never mind
>> the port/auth thing above.)
>> Ideally, it would actually ask what you want your TU credentials to
>> be, but I don't know how flexible the launcher installer system is for
>> adding that sort of thing. I see the obvious argument for not just
>> reusing the provided password. If we're honest, though, a lot of
>> people are going to do it anyway.
>> This seems to be a more general problem, for whatever it's worth. I
>> created a phpMyAdmin instance and never got into it because not only
>> are the PMA credentials…
>> ---
>> $cfg['Servers'][$i]['user'] = $mysql_config["username"];
>> $cfg['Servers'][$i]['password'**] = $mysql_config["password"];
>> (I obviously didn't configure MySQL, so WTH are those?)
>> ---
>> …but it requires Basic auth and there's a *blank* htpasswd file
>> included making it doubly impossible without going through all the
>> command-line/repo/etc. stuff that Launcher seems intended to /avoid/.
>> I want to like this, but right now I'm honestly a bit unclear who it's
>> even for.
Adding Nate to the thread. Launcher has been acquired by Appsembler, Nate's
company, so he is the point-person to help out. I'll be helping him on the
engineering side for a while.
On Sun, Feb 3, 2013 at 9:22 PM, Anil Dash <a...@dashes.com> wrote:
> Hey Maciej, picking this thread back up as I was playing with Launcher
> again today.
> Seems like there's been a good bit of progress, but signing up for ThinkUp
> from here:
> results in a failure to start ThinkUp. My dashboard just says "error" with
> no way to progress. Any idea what's up, or how I could help troubleshoot?
> On Mon, Dec 3, 2012 at 4:30 PM, Maciej Skierkowski <mac...@skierkowski.com
> > wrote:
>> #2 is something that I will fix shortly.
>> #1 is something I could use help with. This problem occurs because of a
>> behavior in Cloud Foundry, so it isn't an issue with Launcher or AppFog,
>> but the technology on which AppFog depends. This means it is an issue with
>> any provider who uses Cloud Foundry. Here is the background. The
>> application gets deployed to a multi-tenant server and each application
>> gets a port number. All the instances are behind a load balancer which
>> forwards requests from port 80 (on the load balancer), to the server/port
>> running the application. ThinkUp uses the local port number with the
>> assumption that it is it's external port number, but it isn't since all
>> requests get forwarded from 80 to that port number. I need a way to tell
>> ThinkUp to generate those URLs without the port number; how can I do that?
>> As a side note, please notice that the link to phpfog.com/thinkup is now
>> broken. It redirects to a generic appfog.com page without a reference to
>> ThinkUp. Obviously I would like to make ThinkUp work well on Launcher but
>> it still requires work, so I totally understand that it isn't ready for
>> prime time. However, because it is borked on phpfog.com I recommend
>> removing the link from thinkupapp.com.
>> On Sunday, November 18, 2012 5:54:50 AM UTC-8, Su wrote:
>>> I tried launcher.io out tonight, and at least as far as ThinkUp, it's
>>> just not ready for promotion. Getting the ThinkUp application
>>> installed at a base level is simple enough, but things just get weird
>>> once you actually try to use it.
>>> --1--
>>> Creating the Twitter app, consumer keys and whatnot, is fine.
>>> But I can't get the application to authenticate a Twitter account
>>> normally.
>>> ThinkUp ends up at a URL like http://thinkup-#####.aws.af.cm (Where
>>> ##### is some generated block of numbers; I did a few installs.) I
>>> hadn't noticed at first, but on the TU Twitter settings page, all of
>>> the provided URLs for app setup(callback, etc) are in the form
>>> http://thinkup-#####.aws.af.**cm:43851/<http://thinkup-#%23%23%23%23.aws.af.cm:43851/>I have no idea where that port
>>> number is coming from; neither Launcher nor AppFog ever display it,
>>> that I've seen. Once you log in at Twitter and allow TU access to your
>>> account, the redirect back ends up timing out.
>>> Figuring the mystery port was the problem, I created a new Twitter app
>>> without the port at all, and the timeout error /still/ wound up there.
>>> But if you let the error occur, strip the port off, and re-submit the
>>> clean URL, authentication goes through immediately.
>>> I'm not even sure if this is a problem for Launcher or AppFog to
>>> address.
>>> --2--
>>> Launcher transparently creates a ThinkUp account for you. This is
>>> understandable considering it's part of the installation process, but
>>> when you pull it apart, it's /really/ weird and confusing:
>>> * Keep in mind this is all happening under a heading that says "Launch
>>> ThinkUp."
>>> * To start the installation process, you're asked to provide an
>>> email/password combination.
>>> * Those credentials are used to either log you in to, or create an
>>> account for you at AppFog, as needed.
>>> * During ThinkUp installation, an account is created using the e-mail
>>> address provided, but NOT the password. (I assume. I used the same
>>> e-mail address for my launcher.io account as for the AppFog one, so
>>> maybe it's coming from there?)
>>> * Once that's finished, you get a link for visiting your new ThinkUp
>>> installation, which you can't log into because you have no idea what
>>> your password is.
>>> * Now you have to go through the "forgot" process to request a reset,
>>> check your e-mail, go back to TU, manually change the password, and
>>> THEN log in, by which point any reasonable person is probably getting
>>> irritated.
>>> Nerds might grumble through this, but if launcher.io is something
>>> that's going to be suggested to people less knowledgeable, what's
>>> going on in this process needs to be clearly documented. (Never mind
>>> the port/auth thing above.)
>>> Ideally, it would actually ask what you want your TU credentials to
>>> be, but I don't know how flexible the launcher installer system is for
>>> adding that sort of thing. I see the obvious argument for not just
>>> reusing the provided password. If we're honest, though, a lot of
>>> people are going to do it anyway.
>>> This seems to be a more general problem, for whatever it's worth. I
>>> created a phpMyAdmin instance and never got into it because not only
>>> are the PMA credentials…
>>> ---
>>> $cfg['Servers'][$i]['user'] = $mysql_config["username"];
>>> $cfg['Servers'][$i]['password'**] = $mysql_config["password"];
>>> (I obviously didn't configure MySQL, so WTH are those?)
>>> ---
>>> …but it requires Basic auth and there's a *blank* htpasswd file
>>> included making it doubly impossible without going through all the
>>> command-line/repo/etc. stuff that Launcher seems intended to /avoid/.
>>> I want to like this, but right now I'm honestly a bit unclear who it's
>>> even for.
> Find out more about ThinkUp:
> http://thinkupapp.com > ---
> You received this message because you are subscribed to the Google Groups
> "ThinkUp" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thinkupapp+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
