With work, family and everything that goes around, it is very hard to be in time...
Standford Class2go gives you half credits if you are late for all the quizzes and exercises but the final exam counted triple so you could skip a few things here and there and still work it out(you had to study them for the exams though!).
I love the fact that there is a due date, it forces me to do it and a certificate is very rewarding too (I tend to give up the courses that give me no "credits")...
I think in general,the schedule are too tight though.
I like Auria, Amplitube,BeatMaker2,iMS20,iSequence,DM1,Animoog,Soundprism and the likes very much.
with audiobus on its way, it is going to get even more interesting.
Been using them for lives & recording demos (iPad+MiC+Jam).
the iPad never crashes(not like Android that freezes a lot).
Obviously you do no get a full pc stack and the quality is still not there so I resort to the Mac for more functionality/sound treatment but you can enjoy quite very much if you can't afford the thousands that cost Native Instruments softs or real hardware synths/drum machines.
The main reason I bought an iPad was... the musical apps (and the fact you can read ebooks with the Kindle app).
The iPad is a revolution in the musical scene.
Musical apps is something you won't get in the Android Eco-system basically because the OS itself sucks at it(although 4.1 seems to have improved a bit on that side).
With this in mind(musical apps), I will always favor the iPad (mini) over an Android tablet.
The new search layout shows very little information,is heavy and crashes now and then(true on 4S but not so on the new iPad where the search result displays more information at once with no crashes so far).
The Genius tab is a real loss for me as I don't use it at all.
I like to browse by category but now I have to tap twice where once was ok...
The result in itself are also plainly wrong most of the time.
I've stopped using it and I've switched to AppShopper, way better(I am absolutely not affiliated with this app^^)
I have at work access to an iPhone 3GS, 4,4S with iOS ranging from 4 to 5. I also have 2 or 3 different handsets of androids to work on.
I personally use an iPhone but all my coworkers androids just keep freezing all the time... (my iPhone 3GS used to freeze before but it was a long time ago...)
On the other hand, since I've switched to the iphone4S, I can say that apps crash really often but I can't tell if it is due to iOS5(thank you Apple for changing really minor dumb stuff at every f'g new version without having a real deprecation rule as Android has) or my way of using the phone(I use way much more apps).
All in all, I can't really tell if iOS apps crashes more than Android but it seems that Android OS is still very buggy yet.
also, statistics are very little weak creatures from which you can extort any figures.
especially,when you read this:
-----------------------------------------
Crittercism, which is backed by Google Ventures, Kleiner Perkins Caufield & Byers, AngelPad, AOL Ventures, Opus Capital and Shasta Ventures, provides crash reporting to app developers.
It does not mean that Perl is not active in Japan though.
Many big companies in Japan uses Perl as the language of choice for their websites but indeed,I won't say that it's not loosing some market share though.
Perl is a really great language that i came to love over the years.
First, I've been writing PHP stuff then moved to Perl and experienced Java,Actionscript,Javascript,Objective-C,Python...
But all of them, Perl was the most powerful and expressive language.
For those who learn Javascript, Perl object literal notation
should be really easy to get and if you do some jQuery stuff, many things should come naturally to you somehow. Perl supports packages, closure, utf8 since many years whereas they are just coming to PHP (It's a real pain to go back to PHP for some projects... as it looks like a huge trash of functions in the global namespace with no cohesion at all... working with array_, mb_ or preg_* functions is such a pain... hopefully the doc helps in understanding the quirks of the language).
The integration of regex as an operator is so nice.
q[] or qq[] helps quite a lot and I quickly miss them...
Controlling each instance of the program flow in code is very powerful too.
I guess the very minimalistic OOP system shipped with Perl did not help get Perl across the board of a wider range of company...
Obviously, this le/gend/ary image of unreadable code that one-liners, and to some extend sysadmin community, gave to the language has left a very bad taste in the mouth... and it is now very hard to get rid of.
when you look at http://mojolicio.us/ or http://perldancer.org/ for web development, Perl::Critic that analyzes your code for bad coding habits(JSLink like), perltidy that reformat your code to follow your conventions or Devel::NYTProf to profile every line of your code...
I don't even talk about CPAN that has always get the job done for me in like 90% of the case...
I still have to find a language that offers such a powerful ecosystem.
And for those who wonder, Perl is very active here in Japan.
> If the specification is to print to STDOUT, a web server needs to make a trick to capture the output using tie, PerlIO or anything else, just like FCGI.pm does, and that's inefficient.
I see. That's a valid point.
So when I asked if by design the protocol would offer better performance, the answer is yes?
Is this inefficiency so bad that changing it to an array ref
brings THAT much improvement though?
It was easy to change the output but I will have to create a thin wrapper around FastCGI/PSGI to make it transparent.
something like this detection done in Mojo becomes necessary:
# PSGI (Plack only for now)
return 'psgi' if defined $ENV{PLACK_ENV};
# CGI
return 'cgi' if defined $ENV{PATH_INFO} || defined $ENV{GATEWAY_INTERFACE};
well, that's not much work...
I'll continue porting the app and see how it behaves.
I've read the entire advent for plack and started to port my app.
- Why send back an array ref instead of using the CGI way?
What is the advantage it brings?
If I want my app to run in a simple FastCGI environment (with the CGI protocol),
this will not be possible anymore so I will be dependent on the Plack suite
or create 2 versions: PSCI enabled and not PSGI enabled (this will not be much but still, 2 is worst than 1).
- Are all the $ENV variables available?
(SCRIPT_NAME for example?)
- All the plack Middleware sounds much like externalized Catalyst modules.
I don't really see what advantages it will bring to framework like Mojolicious for example (they will certainly never ever used any Middleware stuff from the Plack namespace as this is at the heart of their policy so they will just get access to the servers that implements this spec instead of using the normal CGI protocol)
If you put them all back together, you get Catalyst.
So if you start to build a new framework from scratch, yeah, this might be nice.
Everything has been done, you just pick what you want but else...
> Assuming that while loop is in your bootstrap FastCGI script
Yes it is.
> For most web frameworks, the change should be minimal and straightforward
Indeed, it seems so.I'll try it out.
>No, they got a performance boost with our preforking standalone HTTP server,
I was talking about these lines in the article, where Starman is not used at all:
--------
I’ve codenamed the project “PlebGUI“, which I think aptly describes the way it makes it possible for the little people to run WebGUI on low-cost shared hosting.
And it actually works. Take for instance plebgui.patspam.com, a demo PlebGUI site site running in FastCGI mode on HostMonster (the prototypical low-cost shared webhost).
---------
Even though, the application did have even better performance via Starman but it is more a server matter than a PSGI related matter.
>fastpass [...] is XS dependency free (unlike FCGI.pm and CGI::Fast) and the performance is still the same with FCGI.pm, roughly like 4000 requests per second on my laptop, with a simple HelloWorld app via an nginx frontend. I guess we could do even better by doing optional XS parsing with pure perl fallback as well.
> That said, a doc patch is always welcome - on github fork or via RT.
I would like to but I need to understand how this works to provide any patch whatsoever.
What about porting a CGI::Fast application into the PSGI stack then?
while (my $req = CGI::Fast->new) {
myApp->run($req);
}
Is there a handler/wrapper for that?
I've read all the articles but it did not help much.
WebGUI discovered FastCGI via a PSGI implementation but
it's FastCGI who brought the speed, not PSGI per se.
So it brings me back to my point...
> think Apache + FastCGI + CGI::Fast is the best thing in the world and you absolutely need nothing else
I think FastCGI was there to solve indeed a problem and did quite well at doing so. It could be Apache/Nginx/IIS + FastCGI&CGI::Fast, it would work too (Apache/IIS is from experience but Nginx is just an educated guess).
I've decided a long time ago that I will never go the mod_perl way (or at least, will not use their low level access API) then switched to FastCGI and been happy since then.
I still don't get it but perhaps one day it will hit me.
I guess when somebody will bring a "Middleware"
that will meet a need.
In the meantime, I will try to play with it on my spare time. I guess it will be the easiest way to discover what I might be missing...
If DotCloud does not offer this infrastructure(Nginx+FastCGI), it's ok, I still can use our actual providers and it will work (exactly the WebGUI article example for cheap providers!)
Great. perhaps getting rid of it on CPAN could be nice.
> It's not just an "addition" - if there are N frameworks, the caching modules need to be written and maintained for N frameworks
I can not agree with that point. You are almost forgetting CPAN here-which is funny coming from you- (The strength of Perl that many languages do not even dream to have)...
The actual modules were context agnostic and
it's not because you have N frameworks that you MUST have N xxx(caching,session) frameworks.
It's just that some framework authors want to reinvent the wheel.no more, no less(in other languages, without an infrastructure like CPAN this can happen more than it ought to, indeed!).
so the logic: N web framework = N xxx sub frameworks is just biased.
It has always been possible to not duplicate efforts, avoid bugs with different code trying to solve the same problem. It's just that again, some framework did reinvent the wheel where they should have been using what already works (or help on it).
you are just telling me that there is yet an other way of doing the same thing but in the PSGI environment.
All in all, I still don't see what the PSGI spec/protocol and the modules that evolute around bring to the environment.
I don't see why we should have a superset of CGI,which is a language agnostic protocol,that binds with Perl via PSGI.
Really don't get the idea...Is this binding between Perl and the protocol lead to way much better performance?(better than FastCGI?)
I've never used mod_perl as it is only useful for Apache but
I knew that using FastCGI could open me many servers and better performance without having to change much and care about even the language.
I guess my environment is too far from the
problems you seem to encounter and fix.
They are new things where I think, yes, this is going to be good but here, the "pintokita" moment does not arrive at all.
I can only hope that DotCloud will offer a simple support for fastCGI (CGI::Fast) with Nginx.
By the way, adding some script examples for CGI::PSGI and other related modules would be much appreciated (The doc is too elliptic and assume we know already that much about the PSGI context and Plack system)
By the way, I see that you've decided to go with Nginx as the primary server for all languages and this is not really a problem in fact. I don't think switching to Nginx would be much of a hassle.
> I assume you're looking at the non-dev PSGI specification
yes.
> PSGI specification on CPAN
Not really sure it is a good idea to put a spec on CPAN(I know you can find books on CPAN but I really do not think this is the right place for such matters but especially when PSGI/Plack confusion certainly exists.well, that just my view of things)...
Regarding your additions:
>You can stop writing code to support many web server
environments.
As your slide shows, CGI.pm handles quite well many of the environment you list. It has been in development for more than 10years, updated very regularly to fix bugs, even browser based one, the doc is easy to read.
The perl based server you list were built for PSGI in mind so you sell me some candies and the toothbrush that goes with it.
> Your framework can now use all of Plack middleware components.
session, caching,etc. All of these "middleware" already exists since a very long time. so it is just yet an other addition,an other way of doing it.
Some of these PSGI middleware were extracted from Catalyst. Catalyst authors decided to create their own set of engine instead of choosing to use CGI.pm (unlike CGI::Application/Jifty building upon it), linking to your "gross." conclusion- in your slide.
> You can test the application using the consistent L<Plack::Test> interface.
WWW::Mechanize works like a charm for such matters.
(perhaps your Plack::Test differs though, did not look into it so this might be a valid point)
Regarding your slide:
The diagram you show is at best simplistic, at worst wrong
(factcgi->lighttpd).
It deviates from reality to get to your point.
I find the "CGI.pm? meh" slide very disrespectful
and all by itself shows the ambient snobbish attitude towards this very useful module(inherited from the Catalyst community mindset?)
so all in all, I still don't get the problem it is trying
to solve(stealing from python you wrote. an other language, an other culture, an other context)
I still don't get the benefit out of it and why I should use it.
I think I am a lost cause^^; I am sorry.
It's not that I am against new things but here,
I really don't get the advantage of this spec and everything
that goes around.
I have a bootstrap package that launches the FastCGI run loop
then delegates to modules that do there job and print the resulting body at the very end (it's a MVC like framework,nothing fancy) so I don't think it would hurt much to add support for this but I won't do so as long
as I don't get a real + in doing so.
Using Nginx is not much of a matter.
(Nginx+FastCGI should be fine)
In your company or in general?
Because if it's in general, I would be more than happy to see where you get your stats.
> You do Miyagawa a disservice implying he's pumping his own code.
Well, I do think that a not even 2yo spec,a set of modules that are 6~18 months old pushed on a cloud service like that with no back up plan for more "traditional" systems is a way to push its own system. we can agree to disagree on that.
which percentage of providers offer plack with nginx nowadays compared to Apache with FactCGI?
>PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think.
I see.
Perhaps my vision of the state of PSGI is not right indeed.
Nethertheless, my apps run under Fast::CGI
and I really don't see the advantage of PSGI.
> Nobody in their right mind has been using CGI::Fast directly for years
Could you extend on that?
Been using it for years,just works fine.
>PSGI is just a means to present various HTTP bearing things to the app
I really still don't get the benefit though.
But perhaps I should dig into it more
(for now, the python implementation doc was helpful but still did not bring me that much clues as to the real benefits about it)
I love the fact that there is a due date, it forces me to do it and a certificate is very rewarding too (I tend to give up the courses that give me no "credits")...
I think in general,the schedule are too tight though.