Re: Alternative to Google Groups

[dlkinney]

I prefer Google groups.

• Google Groups provides an RSS feed, so 
• I can follow in my RSS reader instead of getting emails or having to sign in to Google
• I can plug in services, such as the automatic re-posting of messages to the group's Twitter account
• Google Groups does not require a Google account to browse the content. It appears that Google+ Communities requires the user to sign in to do anything. This would effectively severe me from the group, as I only have no personal Google account and will not sign up for one. 

On Tuesday, May 14, 2013 1:45:20 PM UTC-5, Joe Nedumgottil wrote:

Just wanted to toss out a suggestion to use something like Google Plus Communities instead of Google Groups (not that I don't like Google Groups of course!).  The community would allow you to post pictures, URL's, and other items in posts, and track events and attendees in a separate area.  Events can even be live-streamed using Google Hangouts.

Many folks use meetups, but I think Google Plus communities might be a pretty nice way to go as well - and does not have a monthly cost.

http://www.google.com/+/learnmore/communities/

Thanks,

Joe

[Fritz Anderson]

On 14 May 2013, at 1:45 PM, Joe Nedumgottil <jnedum...@gmail.com> wrote:

> Many folks use meetups, but I think Google Plus communities might be a pretty nice way to go as well - and does not have a monthly cost.

Except for the cost of feeding more of my life to an organization that says it operates "just short of the line of creepiness," as defined by Google; and by Google's campaign to expand how much creepiness we and the government will find "normal."

I had to submit to Plus to join a work-mandated meetup, and I was appalled to see how much they knew and how much more they'd signed me up to disclose.

I wouldn't participate in any Google Plus activity if I had the choice. If that means I drop CAWUG, those are the breaks.

— F


--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279

[Bob Frank]

Thanks for the suggestion. As you can see, some folks have pretty strong feelings on the issue.

I have no plans to change unless there was an overwhelming call to do so.

-Bob

On May 14, 2013, at 1:45 PM, Joe Nedumgottil wrote:

> Just wanted to toss out a suggestion to use something like Google Plus Communities instead of Google Groups (not that I don't like Google Groups of course!). The community would allow you to post pictures, URL's, and other items in posts, and track events and attendees in a separate area. Events can even be live-streamed using Google Hangouts.
>

> Many folks use meetups, but I think Google Plus communities might be a pretty nice way to go as well - and does not have a monthly cost.
>

> http://www.google.com/+/learnmore/communities/
>
> Thanks,
> Joe

[Matthew Knippen]

I would as well. I think having all of the newer features and the price of admission is a free google account, it is definitely something to look into.

Thanks,
Matthew

On May 16, 2013, at 7:24 AM, Jeffrey Camealy <jcam...@gmail.com> wrote:

> I would appreciate the live streaming of the event.
>
> --
> --
> Chicago CocoaHeads meets the 2nd Tuesday @ 7:00. This group's purpose is to support open discussions for the local Mac & iOS developer community. We encourage your participation.
>
> We either meet at the Chicago Michigan Ave. Apple Store http://tinyurl.com/28q4ro
> Or at 225 W. Wacker, #1700 depending on availability http://tinyurl.com/7ad4zjv
> Follow @NSCoderChicago & @NSLunch for more developer socializing
>
> Job posting rules:
> -Subject must start with [JOB]
> -Focus must be iOS or Mac development
> -State the location. If not in Chicagoland area, is remote ok?
> -recruiters: must explicitly disclose
> -individuals: planning to get a referral fee? you must ask first
> -be concise & include enough detail to understand the job, ex:
> good: build new iOS app to do XYZ
> good: port our desktop app, ABC, to the iPad
> good: help us finish our XYZ app by PDQ date
> bad: maintain our AS/400 enterprise app
>
> To post: ca...@googlegroups.com To unsubscribe: cawug+un...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups "Chicago CocoaHeads (CAWUG)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cawug+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Samuel Hicks]

I have a problem that I was hoping that someone in the community may have some expertise in. I am working on a drawing app. It's too much to get into as far as what it does and why, but at each touchesMoved:withEvent, a process of re-calculating an approximate bezier curve must take place and then redrawn. The approximation algorithm is such that, at any given moment a cubic curve can become quadratic and back. Therefore, the bounding box of the entire curve can change rather drastically point to point.
The naive approach is to simply take the bounds of the bezier curve and pass that to setNeedsDisplayInRect:, that's obviously much, much better than simply calling setNeedsDisplay, but when I profile the code, of course, a huge amount of time is spent inside drawRect. That comes with the problem, but I was hoping to reduce that.
Now, if the stroke call inside of UIBezierPath has sufficient overhead, it could render moot minimizing the volume of the rectangle that needs to be re-drawn. That could be the case, and simply using the naive approach becomes the best alternative. That's possibility #1.
What I was hoping to try, however, was to create an algorithm that minimizes the aggregate volume of a set of rectangles that completely cover the bezier path. In other words, instead of calling setNeedsDisplayInRect once, calling it a few times. The union of the rects completely covers the UIBezierPath. I wish I could write this out more formally in LaTex or something, but I want to reduce the area I need to redraw with the caveat that the entire bezier path is a part of the union of these rects.
Think dominoes. If I can choose from an infinite set of dominoes of every shape and size, how would I go about computing the set of dominoes that cover an arbitrary bezier path such that the volume of the dominoes is minimal.

Thanks for any advice.

Best,
Sam

[Aaron]

Just curious, have you looked at other ways to draw these curves besides drawRect:?

From https://developer.apple.com/library/ios/qa/qa1708/_index.html#//apple_ref/doc/uid/DTS40010245:

"In general, no matter what iOS you're targeting, you should avoid having frequent calls to -drawRect:.

Each UIView is treated as a single element. When you request a redraw, in part or whole, by calling -setNeedsDisplayInRect: or -setNeedsDisplay:, the entire view will be marked for updates."

I'm guessing you won't see many performance gains from the aggregate rectangle approach you're considering (I don't think it'll drastically reduce the amount of time spent in drawRect:).

Do you think it would be possible instead to render a Bézier curve into a CALayer?  You could apply CATransforms for minor changes like stretching and rotating, and only redraw when the curve was significantly different.  You could even experiment with keeping the rendered images in an NSCache collection, and reuse them elsewhere, although it'd probably be premature optimization to start with that.

Aaron Brager

Sent from my iPhone

[Samuel Hicks]

Thanks, Aaron. I'm looking into this. 

[Fritz Anderson]

When I've heard of people bogging down in rendering UIBezierPaths, the suggestion has always been to boost the .flatness property while the shape is in flux, and take the hit of redrawing at optimal flatness just once, when it's stable. The usual case for this is scrolling, where the visual fidelity of an element is not important while it's moving (or at least not as important as keeping up the fidelity of the scrolling physics).

I'd try that first, because once you get into proving topological theorems, and converting them into debugged code, you're overthinking.

— F

[Randy Becker]

Sorry, CAShapeLayer.

-Randy


On May 18, 2013, at 11:18 AM, Randy Becker <lem...@gmail.com> wrote:

> You might try looking into using CAPathLayer instead of using -drawRect:.
>
> -Randy