Re: [ClojureScript] Browser Repl ignores namespace - can't use repl effectively, please help

2015-07-03 Thread David Nolen
Trying to get Cider and nREPL working with ClojureScript is likely to be
more trouble than it's worth. I highly recommend sticking to a simpler
setup -
https://github.com/bhauman/lein-figwheel/wiki/Running-figwheel-with-Emacs-Inferior-Clojure-Interaction-Mode

HTH,
David

On Fri, Jul 3, 2015 at 3:38 AM, Evan Moses  wrote:

> I'm using:  Cider 0.9.1, NRepl 0.2.10, piggieback 0.2.1, fighweel 0.3.1,
> weasel 0.6.0, and clojurescript 3196
>
> I can start a repl, start fighweel, get my browser to connect to it, start
> a weasel browser repl, and evaluate code.  What I can't do is anything
> involving a namespace.  When I switch namespaces in Cider, it looks like it
> switches; it can even autocomplete them.  However, whenever I try to
> evaluate any symbol at all, I get a stack trace like this:
>
> cljs.user> (ns octo-repos.background.github)
> octo-repos.background.github> get-repo-info
> WARNING: Use of undeclared Var /get-repo-info at line 1 
> #
> SyntaxError: Unexpected token .
> at http://localhost:3449/js/out/weasel/repl.js:28:470
> at http://localhost:3449/js/out/weasel/repl.js:37:4
> at cljs.core.MultiFn.call.G__11126__2 (
> http://localhost:3449/js/out/cljs/core.js:30919:113)
> at cljs.core.MultiFn.call.G__11126 [as call] (
> http://localhost:3449/js/out/cljs/core.js:31623:20)
> at null. (
> http://localhost:3449/js/out/weasel/repl.js:137:71)
> at goog.events.EventTarget.fireListeners (
> http://localhost:3449/js/out/goog/events/eventtarget.js:285:23)
> at Function.goog.events.EventTarget.dispatchEventInternal_ (
> http://localhost:3449/js/out/goog/events/eventtarget.js:382:26)
> at goog.events.EventTarget.dispatchEvent (
> http://localhost:3449/js/out/goog/events/eventtarget.js:197:34)
> at goog.net.WebSocket.onMessage_ (
> http://localhost:3449/js/out/goog/net/websocket.js:411:8)
>
> If I fully qualify all the symbols, though, it works:
>
>  octo-repos.background.github> octo-repos.background.github/get-repo-info
> WARNING: No such namespace: octo-repos.background.github, could not locate
> octo_repos/background/github.cljs or octo_repos/background/github.cljc at
> line 1 
> WARNING: Use of undeclared Var octo-repos.background.github/get-repo-info
> at line 1 
> # ..
>
> Note that I get a warning about the undelcared var even though it
> successfully evaluates.  This one's fun:
>
> octo-repos.background.github> (def foo "foo")
> #
> SyntaxError: Unexpected token .
> at http://localhost:3449/js/out/weasel/repl.js:28:470
> at http://localhost:3449/js/out/weasel/repl.js:37:4
> ...same stack trace as above
>
> I actually tried to trace what was going on.  From my nrepl log, things
> look OK, you can see it's sending the namespace.
>
> (--->
>   ns  "octo-repos.background.github"
>   op  "eval"
>   session  "72a36d52-6b36-41b7-b0b5-da44f3971e06"
>   code  "(def foo \"foo\")\n"
>   id  "36"
> )
> (<-
>   ex  "class clojure.lang.ExceptionInfo"
>   id  "36"
>   root-ex  "class clojure.lang.ExceptionInfo"
>   session  "72a36d52-6b36-41b7-b0b5-da44f3971e06"
>   status  ("eval-error")
> )
>
> But by the time it gets to the browser, the code that it's asked to eval
> looks like this [This is from (def f "hi"), but same idea]:
>
> "(function (){try{return cljs.core.pr_str.call(null,(function (){var
> ret__5132__auto__ = .f = "hi"; cljs.core._STAR_3 = cljs.core._STAR_2;
> cljs.core._STAR_2 = cljs.core._STAR_1; cljs.core._STAR_1 =
> ret__5132__auto__; return ret__5132__auto__; })()); }catch (e24906){var
> e__5133__auto__ = e24906; cljs.core._STAR_e = e__5133__auto__; throw
> e__5133__auto__; }})()"
>
> So, I'm at a loss, I don't even know which component is causing the
> problem. I actually *can* use the repl, but I have to type out the
> namespace for every symbol.  Can anyone help?  Thanks
>
> --
> Evan
>
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescript@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.


Re: [ClojureScript] Re: Startups that bank on Clojure/Script

2015-07-03 Thread Matt Ho
@colin Couldn't agree with your comments on remote working more.  The challenge 
for many early stage companies is that they require incredibly high levels of 
communication to be on the same page.  

I also think part of the remote/onsite issue is the difference between 
efficient and effective.  The pro camp seems to focus on efficiency (let me get 
work done) and the onsite camp focuses on effectiveness (communicate so we can 
do the right work done).  Depends on where you are.

@marc The best way to attract an amazing community around cljs is to show 
people how you can build amazing products with it without a steep learning 
curve.  If you think of cljs as a product, then learning curve can be thought 
of as the price you pay to benefit from it.  Make that price low to free and 
show lots of value (e.g. ReactJS) and you'll get wide adoption.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.


Re: [ClojureScript] Performance tuning a Reagent/Re-frame application

2015-07-03 Thread Russell Dunphy
Ah, got you! That's a good idea, will give it a go, thanks.

On Friday, July 3, 2015 at 5:12:45 PM UTC+1, Colin Yates wrote:
> Hi Russel, I often find my intuition as to where the problem is when it comes 
> to performance is about as bad as my estimates (i.e. terrible) so I 
> ruthlessly reduce the problem. In this case, is the performance problem in JS 
> or simple rendering the DOM. One way to do that is use your app to render 
> page 1 and inspect the HTML. Copy that HTML into a file called ‘page1.htm. 
> Now use your app to transition to another page which is considered ‘slow’ and 
> inspect the HTML. Copy that to a file called page2.htm. Now edit page1.htm 
> and add a link to page2.htm. You now have a reduced problem set where there 
> is absolutely no JS and is pure rendering.
> 
> Now, load page1.htm in the browser - how quick was that? Now click the 
> transition button and wait for it to be rendered - how quick was that? It is 
> sometimes surprising how long this takes, even without the overhead of 
> JavaScript. At least now I am guided to whether the slog is in rendering the 
> DOM (in which case chunking the DOM updates is one answer) or somewhere else.
> 
> That’s all I meant.
> 
> > On 3 Jul 2015, at 17:06, Russell Dunphy  wrote:
> > 
> > Thanks Colin! The only one I'm not sure I follow is to "copy the rendered 
> > HTML from page1 and page2 into static HTML files". Is this for the special 
> > case where you don't have any dynamic content on the page? Or are you 
> > talking about rendering the generic structure of the page first, then 
> > loading in actual data?
> > 
> > On Friday, July 3, 2015 at 4:13:36 PM UTC+1, Colin Yates wrote:
> >> I notice (subjectively) that Chrome is generally a *lot* faster when 
> >> running JS heavy apps than Firefox or, please no - IE<11.
> >> 
> >> 
> >> A few tips, I am sure you are already doing:
> >>  - only render what is needed, don’t use ‘hidden’ as they are still in the 
> >> DOM
> >>  - copy the rendered HTML from page1 and page2 into static HTML files and 
> >> then add an " >> leaves you with the faster you are going to get
> >>  - read and digest 
> >> https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem
> >>  - identify the ‘real' performance bottlenecks; sure it may displease you, 
> >> but will the users really care? What else could you be giving them if you 
> >> didn’t have to work on this? This is a note to me more than you :).
> >> 
> >> 
> >> HTH and if you find any other tips then shout loudly!
> >> 
> >> 
> >> 
> >> On 3 Jul 2015, at 15:42, Russell Dunphy  wrote:
> >> 
> >> Does anyone have any tips for performance tuning a reagent/re-frame 
> >> application they can share? We're running into very slow rendering 
> >> performance when changing pages on Firefox on Windows  (ie sometimes 
> >> several seconds) which, though still noticeably laggy, don't seem to be 
> >> anywhere near as much of a problem in Chrome.
> >> 
> >> Unfortunately I can't share the codebase, but here's what we've been 
> >> trying so far:
> >> 
> >> Using React.addons.Perf to identify components that take more data than 
> >> they need as arguments - i.e their render function is called with changed 
> >> data but they don't end up generating different markup. This has helped us 
> >> reduce *re-render* performance, but doesn't help us much on initial page 
> >> render, where is where our performance problems mainly lie.
> >> 
> >> Wrapping all our subscriptions using our own [custom register sub 
> >> function](https://gist.github.com/rsslldnphy/5c937167380dd3442076) to 
> >> track how many times each subscription is called, how long it takes etc, 
> >> to reduce duplicated work and highlight inefficiences. This has helped us 
> >> a bit, but slowness still remains.
> >> 
> >> To give a slightly better UX when moving between pages, we first update 
> >> the app state with a key that causes a loading spinner to appear, then 
> >> call reagent/flush to make sure it's rendered, *then* update the app state 
> >> again to trigger the change to the new page. This still ends up being a 
> >> bit jerky however (the gif often freezes while the page is rendering, or 
> >> itself takes a while to appear) so any better suggestions would be very 
> >> welcome.
> >> 
> >> Thanks in advance for your suggestions.
> >> 
> >> Russell
> >> 
> >> -- 
> >> Note that posts from new members are moderated - please be patient with 
> >> your first post.
> >> --- 
> >> You received this message because you are subscribed to the Google Groups 
> >> "ClojureScript" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to clojurescrip...@googlegroups.com.
> >> To post to this group, send email to clojur...@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/clojurescript.
> > 
> > -- 
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > --- 
> > You received this me

Re: [ClojureScript] Performance tuning a Reagent/Re-frame application

2015-07-03 Thread Colin Yates
Hi Russel, I often find my intuition as to where the problem is when it comes 
to performance is about as bad as my estimates (i.e. terrible) so I ruthlessly 
reduce the problem. In this case, is the performance problem in JS or simple 
rendering the DOM. One way to do that is use your app to render page 1 and 
inspect the HTML. Copy that HTML into a file called ‘page1.htm. Now use your 
app to transition to another page which is considered ‘slow’ and inspect the 
HTML. Copy that to a file called page2.htm. Now edit page1.htm and add a link 
to page2.htm. You now have a reduced problem set where there is absolutely no 
JS and is pure rendering.

Now, load page1.htm in the browser - how quick was that? Now click the 
transition button and wait for it to be rendered - how quick was that? It is 
sometimes surprising how long this takes, even without the overhead of 
JavaScript. At least now I am guided to whether the slog is in rendering the 
DOM (in which case chunking the DOM updates is one answer) or somewhere else.

That’s all I meant.

> On 3 Jul 2015, at 17:06, Russell Dunphy  wrote:
> 
> Thanks Colin! The only one I'm not sure I follow is to "copy the rendered 
> HTML from page1 and page2 into static HTML files". Is this for the special 
> case where you don't have any dynamic content on the page? Or are you talking 
> about rendering the generic structure of the page first, then loading in 
> actual data?
> 
> On Friday, July 3, 2015 at 4:13:36 PM UTC+1, Colin Yates wrote:
>> I notice (subjectively) that Chrome is generally a *lot* faster when running 
>> JS heavy apps than Firefox or, please no - IE<11.
>> 
>> 
>> A few tips, I am sure you are already doing:
>>  - only render what is needed, don’t use ‘hidden’ as they are still in the 
>> DOM
>>  - copy the rendered HTML from page1 and page2 into static HTML files and 
>> then add an "> leaves you with the faster you are going to get
>>  - read and digest 
>> https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem
>>  - identify the ‘real' performance bottlenecks; sure it may displease you, 
>> but will the users really care? What else could you be giving them if you 
>> didn’t have to work on this? This is a note to me more than you :).
>> 
>> 
>> HTH and if you find any other tips then shout loudly!
>> 
>> 
>> 
>> On 3 Jul 2015, at 15:42, Russell Dunphy  wrote:
>> 
>> Does anyone have any tips for performance tuning a reagent/re-frame 
>> application they can share? We're running into very slow rendering 
>> performance when changing pages on Firefox on Windows  (ie sometimes several 
>> seconds) which, though still noticeably laggy, don't seem to be anywhere 
>> near as much of a problem in Chrome.
>> 
>> Unfortunately I can't share the codebase, but here's what we've been trying 
>> so far:
>> 
>> Using React.addons.Perf to identify components that take more data than they 
>> need as arguments - i.e their render function is called with changed data 
>> but they don't end up generating different markup. This has helped us reduce 
>> *re-render* performance, but doesn't help us much on initial page render, 
>> where is where our performance problems mainly lie.
>> 
>> Wrapping all our subscriptions using our own [custom register sub 
>> function](https://gist.github.com/rsslldnphy/5c937167380dd3442076) to track 
>> how many times each subscription is called, how long it takes etc, to reduce 
>> duplicated work and highlight inefficiences. This has helped us a bit, but 
>> slowness still remains.
>> 
>> To give a slightly better UX when moving between pages, we first update the 
>> app state with a key that causes a loading spinner to appear, then call 
>> reagent/flush to make sure it's rendered, *then* update the app state again 
>> to trigger the change to the new page. This still ends up being a bit jerky 
>> however (the gif often freezes while the page is rendering, or itself takes 
>> a while to appear) so any better suggestions would be very welcome.
>> 
>> Thanks in advance for your suggestions.
>> 
>> Russell
>> 
>> -- 
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojurescrip...@googlegroups.com.
>> To post to this group, send email to clojur...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/clojurescript.
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescript@googlegroups.com.
> Visit this group at http://groups.google.c

Re: [ClojureScript] Performance tuning a Reagent/Re-frame application

2015-07-03 Thread Russell Dunphy
Thanks Colin! The only one I'm not sure I follow is to "copy the rendered HTML 
from page1 and page2 into static HTML files". Is this for the special case 
where you don't have any dynamic content on the page? Or are you talking about 
rendering the generic structure of the page first, then loading in actual data?

On Friday, July 3, 2015 at 4:13:36 PM UTC+1, Colin Yates wrote:
> I notice (subjectively) that Chrome is generally a *lot* faster when running 
> JS heavy apps than Firefox or, please no - IE<11.
> 
> 
> A few tips, I am sure you are already doing:
>  - only render what is needed, don’t use ‘hidden’ as they are still in the DOM
>  - copy the rendered HTML from page1 and page2 into static HTML files and 
> then add an " leaves you with the faster you are going to get
>  - read and digest 
> https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem
>  - identify the ‘real' performance bottlenecks; sure it may displease you, 
> but will the users really care? What else could you be giving them if you 
> didn’t have to work on this? This is a note to me more than you :).
> 
> 
> HTH and if you find any other tips then shout loudly!
> 
> 
> 
> On 3 Jul 2015, at 15:42, Russell Dunphy  wrote:
> 
> Does anyone have any tips for performance tuning a reagent/re-frame 
> application they can share? We're running into very slow rendering 
> performance when changing pages on Firefox on Windows  (ie sometimes several 
> seconds) which, though still noticeably laggy, don't seem to be anywhere near 
> as much of a problem in Chrome.
> 
> Unfortunately I can't share the codebase, but here's what we've been trying 
> so far:
> 
> Using React.addons.Perf to identify components that take more data than they 
> need as arguments - i.e their render function is called with changed data but 
> they don't end up generating different markup. This has helped us reduce 
> *re-render* performance, but doesn't help us much on initial page render, 
> where is where our performance problems mainly lie.
> 
> Wrapping all our subscriptions using our own [custom register sub 
> function](https://gist.github.com/rsslldnphy/5c937167380dd3442076) to track 
> how many times each subscription is called, how long it takes etc, to reduce 
> duplicated work and highlight inefficiences. This has helped us a bit, but 
> slowness still remains.
> 
> To give a slightly better UX when moving between pages, we first update the 
> app state with a key that causes a loading spinner to appear, then call 
> reagent/flush to make sure it's rendered, *then* update the app state again 
> to trigger the change to the new page. This still ends up being a bit jerky 
> however (the gif often freezes while the page is rendering, or itself takes a 
> while to appear) so any better suggestions would be very welcome.
> 
> Thanks in advance for your suggestions.
> 
> Russell
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescrip...@googlegroups.com.
> To post to this group, send email to clojur...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.


Re: [ClojureScript] Performance tuning a Reagent/Re-frame application

2015-07-03 Thread Colin Yates
I notice (subjectively) that Chrome is generally a *lot* faster when running JS 
heavy apps than Firefox or, please no - IE<11.

A few tips, I am sure you are already doing:
 - only render what is needed, don’t use ‘hidden’ as they are still in the DOM
 - copy the rendered HTML from page1 and page2 into static HTML files and then 
add an "https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem 

 - identify the ‘real' performance bottlenecks; sure it may displease you, but 
will the users really care? What else could you be giving them if you didn’t 
have to work on this? This is a note to me more than you :).

HTH and if you find any other tips then shout loudly!

> On 3 Jul 2015, at 15:42, Russell Dunphy  wrote:
> 
> Does anyone have any tips for performance tuning a reagent/re-frame 
> application they can share? We're running into very slow rendering 
> performance when changing pages on Firefox on Windows  (ie sometimes several 
> seconds) which, though still noticeably laggy, don't seem to be anywhere near 
> as much of a problem in Chrome.
> 
> Unfortunately I can't share the codebase, but here's what we've been trying 
> so far:
> 
> Using React.addons.Perf to identify components that take more data than they 
> need as arguments - i.e their render function is called with changed data but 
> they don't end up generating different markup. This has helped us reduce 
> *re-render* performance, but doesn't help us much on initial page render, 
> where is where our performance problems mainly lie.
> 
> Wrapping all our subscriptions using our own [custom register sub 
> function](https://gist.github.com/rsslldnphy/5c937167380dd3442076) to track 
> how many times each subscription is called, how long it takes etc, to reduce 
> duplicated work and highlight inefficiences. This has helped us a bit, but 
> slowness still remains.
> 
> To give a slightly better UX when moving between pages, we first update the 
> app state with a key that causes a loading spinner to appear, then call 
> reagent/flush to make sure it's rendered, *then* update the app state again 
> to trigger the change to the new page. This still ends up being a bit jerky 
> however (the gif often freezes while the page is rendering, or itself takes a 
> while to appear) so any better suggestions would be very welcome.
> 
> Thanks in advance for your suggestions.
> 
> Russell
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescript@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.


[ClojureScript] Performance tuning a Reagent/Re-frame application

2015-07-03 Thread Russell Dunphy
Does anyone have any tips for performance tuning a reagent/re-frame application 
they can share? We're running into very slow rendering performance when 
changing pages on Firefox on Windows  (ie sometimes several seconds) which, 
though still noticeably laggy, don't seem to be anywhere near as much of a 
problem in Chrome.

Unfortunately I can't share the codebase, but here's what we've been trying so 
far:

Using React.addons.Perf to identify components that take more data than they 
need as arguments - i.e their render function is called with changed data but 
they don't end up generating different markup. This has helped us reduce 
*re-render* performance, but doesn't help us much on initial page render, where 
is where our performance problems mainly lie.

Wrapping all our subscriptions using our own [custom register sub 
function](https://gist.github.com/rsslldnphy/5c937167380dd3442076) to track how 
many times each subscription is called, how long it takes etc, to reduce 
duplicated work and highlight inefficiences. This has helped us a bit, but 
slowness still remains.

To give a slightly better UX when moving between pages, we first update the app 
state with a key that causes a loading spinner to appear, then call 
reagent/flush to make sure it's rendered, *then* update the app state again to 
trigger the change to the new page. This still ends up being a bit jerky 
however (the gif often freezes while the page is rendering, or itself takes a 
while to appear) so any better suggestions would be very welcome.

Thanks in advance for your suggestions.

Russell

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.


Re: [ClojureScript] Re: Startups that bank on Clojure/Script

2015-07-03 Thread Alan Moore
Ah, my bad. I should have considered the issue of problem domains. For my
day job I don't work in an "enterprise" or business consulting context. I
build specialty hardware products where just making it work is job #1,
reliability is #2, time to market is #3. Feedback from product management
is limited at best and primarily given up front, modulo some UI tweaking.

Also, when I used to work in more typical sw projects, remote teams worked
best when everyone is remote. Hallway conversations short circuit the
communications and remote engineers are at a disadvantage unless there is
good discipline/sharing.

I think this thread has gone somewhat off topic so further discussion
should probably be carried on off list. I can be reached @coopsource on
Twitter.

Alan
-- 
*"Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now."* - *Goethe*

On Jul 3, 2015, at 2:29 AM, Colin Yates  wrote:

Having worked remotely for nearly a decade I can say that when it works
well it is unbeatable in terms of productivity, satisfaction, home/work
balance and so on. When it works badly it is unbeatable in terms of lack of
productivity, lack of satisfaction etc.

Delivering the software that the business wants depends far less on
developer productivity then it does on communication. By orders of
magnitude. I realise that we as developers are highly skilled, creative,
specialist/generalists and so on, but I have seen many more projects that
were built well but delivered the wrong thing then projects that failed
because of developer insufficiency. Almost always because there is inherent
ambiguity translating:
- what the business _thinks_ they want
- what the business _meant_ to ask for
- what the team _heard_ the business ask for
- what the developers _interpreted_ those requirements to be

It is communication that is our achille’s heel, not distraction, skill or
tooling.

For me, if I haven’t sat down face to face and shown the key stake holders
a realisation (i.e. working software) of what they asked for every other
week or so I get very twitchy.

Of course, when there is a whole bunch of hidden complexity to solve then
sure, working from home and getting your head down is great. All I am
saying is that for the project as a whole, it can be exacerbate the
fundamental thing success depends on - getting you and them in a room
demonstrating what they asked for.

I should also say that a lot of developers (in my non-scientific and
non-validated opinion) are prone to introspection and depression and
isolation, which is sometimes what they most crave can be the absolute last
thing they need.

My advice - work from home sure, but regularly get into the same room
(Skype really doesn’t cut it. FaceTime neither as then you need to remember
to put your pants on before work!) with the key stake holders and other
team mates. Also make sure you have a _very_ disciplined and structured
process for separating home and work life.

Anyway, enough ramblings from me.


On 3 Jul 2015, at 03:02, Marc Fawzi  wrote:



"The future has arrived, but it's not evenly distributed" -- William Gibson


I think the "remote vs in the office" issue is ultimately about our ability
to achieve "eventual consistency" with the rest of the team on multiple
levels spanning the inter-personal, cultural, process oriented and
technical domains.


But the truth in today's work environment is that being in the office is
less productive than working from your own office where you can shut out
all distractions. It reduces productivity and increases distraction and
therefore software defects by a critical amount and it does not solve the
problem of getting everyone on the same page; it only alleviates it. Raw
productivity is not the goal, so many companies prefer to bring people
under one roof than let them loose on independent projects or going in
separate directions on the same thing.


I think we could use better tooling for the remote lifestyle to make sense
in the common scenario. But the tools for collaboration that we have are so
so. Myself, i feel like a good balance can be attained between productivity
and mission coherence. Maybe I'm wrong?


Sent from my iPhone


On Jul 2, 2015, at 2:17 PM, Joe R. Smith  wrote:


Having worked remotely for a couple years now, I can definitely say I’m far
more productive.


This sums up why:
http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/


On Jul 2, 2015, at 4:14 PM, Alan Moore  wrote:


When constrained by a technology choice you may have to give up requiring
other developers to be physically proximate.


I know managers want the comfort of observing warm bodies in cubes banging
on keyboards but it doesn't necessarily translate into higher productivity,
I get my best work done when everyone else goes home.


I've worked for  in cubes emailing co-workers in their
cubes and I see no reason why we even have to be in the same building...
confounding actually,

[ClojureScript] Browser Repl ignores namespace - can't use repl effectively, please help

2015-07-03 Thread Evan Moses
I'm using:  Cider 0.9.1, NRepl 0.2.10, piggieback 0.2.1, fighweel 0.3.1, weasel 
0.6.0, and clojurescript 3196

I can start a repl, start fighweel, get my browser to connect to it, start a 
weasel browser repl, and evaluate code.  What I can't do is anything involving 
a namespace.  When I switch namespaces in Cider, it looks like it switches; it 
can even autocomplete them.  However, whenever I try to evaluate any symbol at 
all, I get a stack trace like this: 

cljs.user> (ns octo-repos.background.github)
octo-repos.background.github> get-repo-info
WARNING: Use of undeclared Var /get-repo-info at line 1 
#
SyntaxError: Unexpected token .
at http://localhost:3449/js/out/weasel/repl.js:28:470
at http://localhost:3449/js/out/weasel/repl.js:37:4
at cljs.core.MultiFn.call.G__11126__2 
(http://localhost:3449/js/out/cljs/core.js:30919:113)
at cljs.core.MultiFn.call.G__11126 [as call] 
(http://localhost:3449/js/out/cljs/core.js:31623:20)
at null. (http://localhost:3449/js/out/weasel/repl.js:137:71)
at goog.events.EventTarget.fireListeners 
(http://localhost:3449/js/out/goog/events/eventtarget.js:285:23)
at Function.goog.events.EventTarget.dispatchEventInternal_ 
(http://localhost:3449/js/out/goog/events/eventtarget.js:382:26)
at goog.events.EventTarget.dispatchEvent 
(http://localhost:3449/js/out/goog/events/eventtarget.js:197:34)
at goog.net.WebSocket.onMessage_ 
(http://localhost:3449/js/out/goog/net/websocket.js:411:8)

If I fully qualify all the symbols, though, it works:

 octo-repos.background.github> octo-repos.background.github/get-repo-info
WARNING: No such namespace: octo-repos.background.github, could not locate 
octo_repos/background/github.cljs or octo_repos/background/github.cljc at line 
1 
WARNING: Use of undeclared Var octo-repos.background.github/get-repo-info at 
line 1 
#...

Note that I get a warning about the undelcared var even though it successfully 
evaluates.  This one's fun:

octo-repos.background.github> (def foo "foo")
#
SyntaxError: Unexpected token .
at http://localhost:3449/js/out/weasel/repl.js:28:470
at http://localhost:3449/js/out/weasel/repl.js:37:4
...same stack trace as above

I actually tried to trace what was going on.  From my nrepl log, things look 
OK, you can see it's sending the namespace.  

(--->
  ns  "octo-repos.background.github"
  op  "eval"
  session  "72a36d52-6b36-41b7-b0b5-da44f3971e06"
  code  "(def foo \"foo\")\n"
  id  "36"
)
(<-
  ex  "class clojure.lang.ExceptionInfo"
  id  "36"
  root-ex  "class clojure.lang.ExceptionInfo"
  session  "72a36d52-6b36-41b7-b0b5-da44f3971e06"
  status  ("eval-error")
)

But by the time it gets to the browser, the code that it's asked to eval looks 
like this [This is from (def f "hi"), but same idea]:

"(function (){try{return cljs.core.pr_str.call(null,(function (){var 
ret__5132__auto__ = .f = "hi"; cljs.core._STAR_3 = cljs.core._STAR_2; 
cljs.core._STAR_2 = cljs.core._STAR_1; cljs.core._STAR_1 = ret__5132__auto__; 
return ret__5132__auto__; })()); }catch (e24906){var e__5133__auto__ = e24906; 
cljs.core._STAR_e = e__5133__auto__; throw e__5133__auto__; }})()"

So, I'm at a loss, I don't even know which component is causing the problem. I 
actually *can* use the repl, but I have to type out the namespace for every 
symbol.  Can anyone help?  Thanks

--
Evan


-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.


[ClojureScript] [cljs-ajax] how to post json data like CURL ?

2015-07-03 Thread Bin Li
I have spring contoler which talking json like :

@RequestMapping(value = "/todos/delete", method = RequestMethod.POST)
public String deleteTodo(@RequestBody Todo todo, Model model) {

logger.info("/todos/delete : todo = " + todo);
String status = "ok";
int num = 0;
try {
int id = todo.getId();
num = todoMapper.deleteByPrimaryKey(id);
} catch (Exception e) {
logger.error("/todos/delete failed : " + e);
status = "fail";
}

// result
model.addAttribute("out", "deleted " + num + " todo(s)");
model.addAttribute("status", status);
return jsonTemplate;
}

With curl , I can post it like:

curl -H "Content-Type: application/json" -X POST -d "{\"id\":1}" 
http://localhost:8080/todo/todos/delete

Then I can get todo initialized.

But if I post with JulianBirch/cljs-ajax :

  (ajax/POST "/todo/todos/delete"
  {:format :json
   :response-format :json  
   :handler #(dispatch [:handle-del-resp %1])
   :error-handler #(dispatch [:handle-error %1])
   :params {"id" id}})

I am getting todo return null.

Any point will be appreciated, thanks in advanced!



-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.


Re: [ClojureScript] Re: Startups that bank on Clojure/Script

2015-07-03 Thread Colin Yates
Having worked remotely for nearly a decade I can say that when it works well it 
is unbeatable in terms of productivity, satisfaction, home/work balance and so 
on. When it works badly it is unbeatable in terms of lack of productivity, lack 
of satisfaction etc.

Delivering the software that the business wants depends far less on developer 
productivity then it does on communication. By orders of magnitude. I realise 
that we as developers are highly skilled, creative, specialist/generalists and 
so on, but I have seen many more projects that were built well but delivered 
the wrong thing then projects that failed because of developer insufficiency. 
Almost always because there is inherent ambiguity translating:
 - what the business _thinks_ they want
 - what the business _meant_ to ask for
 - what the team _heard_ the business ask for
 - what the developers _interpreted_ those requirements to be

It is communication that is our achille’s heel, not distraction, skill or 
tooling.

For me, if I haven’t sat down face to face and shown the key stake holders a 
realisation (i.e. working software) of what they asked for every other week or 
so I get very twitchy.

Of course, when there is a whole bunch of hidden complexity to solve then sure, 
working from home and getting your head down is great. All I am saying is that 
for the project as a whole, it can be exacerbate the fundamental thing success 
depends on - getting you and them in a room demonstrating what they asked for.

I should also say that a lot of developers (in my non-scientific and 
non-validated opinion) are prone to introspection and depression and isolation, 
which is sometimes what they most crave can be the absolute last thing they 
need.

My advice - work from home sure, but regularly get into the same room (Skype 
really doesn’t cut it. FaceTime neither as then you need to remember to put 
your pants on before work!) with the key stake holders and other team mates. 
Also make sure you have a _very_ disciplined and structured process for 
separating home and work life.

Anyway, enough ramblings from me.


> On 3 Jul 2015, at 03:02, Marc Fawzi  wrote:
> 
> 
> "The future has arrived, but it's not evenly distributed" -- William Gibson 
> 
> I think the "remote vs in the office" issue is ultimately about our ability 
> to achieve "eventual consistency" with the rest of the team on multiple 
> levels spanning the inter-personal, cultural, process oriented and technical 
> domains.
> 
> But the truth in today's work environment is that being in the office is less 
> productive than working from your own office where you can shut out all 
> distractions. It reduces productivity and increases distraction and therefore 
> software defects by a critical amount and it does not solve the problem of 
> getting everyone on the same page; it only alleviates it. Raw productivity is 
> not the goal, so many companies prefer to bring people under one roof than 
> let them loose on independent projects or going in separate directions on the 
> same thing. 
> 
> I think we could use better tooling for the remote lifestyle to make sense in 
> the common scenario. But the tools for collaboration that we have are so so. 
> Myself, i feel like a good balance can be attained between productivity and 
> mission coherence. Maybe I'm wrong?
> 
> Sent from my iPhone
> 
>> On Jul 2, 2015, at 2:17 PM, Joe R. Smith  wrote:
>> 
>> Having worked remotely for a couple years now, I can definitely say I’m far 
>> more productive. 
>> 
>> This sums up why: 
>> http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/
>> 
>>> On Jul 2, 2015, at 4:14 PM, Alan Moore  wrote:
>>> 
>>> When constrained by a technology choice you may have to give up requiring 
>>> other developers to be physically proximate.
>>> 
>>> I know managers want the comfort of observing warm bodies in cubes banging 
>>> on keyboards but it doesn't necessarily translate into higher productivity, 
>>> I get my best work done when everyone else goes home.
>>> 
>>> I've worked for  in cubes emailing co-workers in their 
>>> cubes and I see no reason why we even have to be in the same building... 
>>> confounding actually, "stand-ups" not withstanding :-0
>>> 
>>> Alan
>>> 
 On Wednesday, July 1, 2015 at 3:33:22 PM UTC-7, Nate Wildermuth wrote:
 Interesting questions! 
 
 The startup I work for (Nowthis News) made the switch to Clojurescript a 
 few months ago, but I don't think our VCs care much about our tech stack. 
 In my experience, they focus on metrics like growth rates, users, and 
 views.
 
 On hiring and employment, I can't imagine working anywhere else. I get to 
 program in lisp all day long. But I haven't had much luck finding people 
 to join my team. Would love to hear from anyone who's had success on that 
 front!
>>> 
>>> -- 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> --- 
>>