minify static files (css and js)
Hi I have always wanted to minify my css and js but it never seemed like the right time to do it. Somehow there is always something I know I want to tweak first so I'll release it as is for now... :) Having used the django-staticfiles app for some time now I just realised that that would actually be the perfect place to implement minify functionality. I think it will make minification a standard for many sites if css and js files got minified when you run collectstatic. Not sure what the implications would be just sharing a thought. Regards Gert -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: minify static files (css and js)
Hello, You're probably looking for: https://github.com/jezdez/django_compressor Best regards, -- Aymeric Augustin. On 7 août 2011, at 14:36, gert wrote: > Hi > > I have always wanted to minify my css and js but it never seemed like > the right time to do it. Somehow there is always something I know I > want to tweak first so I'll release it as is for now... :) > > Having used the django-staticfiles app for some time now I just > realised that that would actually be the perfect place to implement > minify functionality. I think it will make minification a standard for > many sites if css and js files got minified when you run > collectstatic. > > Not sure what the implications would be just sharing a thought. > > Regards > Gert > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 Roadmap
On Sat, Aug 6, 2011 at 6:16 PM, Srik wrote: > Hello All, > > I believe https://code.djangoproject.com/wiki/Version1.4Roadmap needs > update badly considering 1.3 was released 4 months ago and 1.4 Roadmap > was never updated. Agreed -- we haven't been very good with public plans for the 1.4 cycle. Internally, the core team had some discussions about some more aggressive dates that would lead to faster cycles, but those dates sailed past a long time ago. At this point, I think we should be aiming at DjangoCon as a deadline for the Alpha; with beta and final following at roughly 1 month increments after that, which would produce a 1.4 release around the end of November. However, I hasten to add: 1) I haven't discussed these dates with the rest of the core team, 2) The real impediment to getting a release out the door is having someone who has the spare time to manage the release process. That's been me for the last two releases; I'm fairly certain I won't have the spare cycles to make it three in a row. > There seems to be good amount of work going on as per commits to trunk > but what exactly are the goals of 1.4. > > Will it be mainly bug fix (closing existing tickets) or can we expect > any new features (If so do we have a list elsewhere towards which > developers are working)? The feature list of 1.4 isn't likely to have a bunch of massive features like 1.2; it's more likely to be like 1.3. That is, a couple of big features, and a bunch of bugfixes. *Which* features is mostly up to the community. Essentially, the final feature list for 1.4 will be determined by the list of RFC patches that are submitted. Some of those will be contributed by core developers, some will come from the general community. Bigger features will need some buy-in from a core developer if they're going to get committed. The lesson we've learned from the 1.1 and 1.2 cycles is that it doesn't matter what someone wants to put on a feature list -- what matters is actually producing the patch. So, it's better to set a date and cut a release based on the features available at that date, rather than wait for delivery of a feature that many people have expressed an interest in, but nobody has worked on. The moral of this story -- if there's a feature you want, *you* have to make it happen, by writing patches, engaging the community, and convincing a core developer that it's a must-have feature with community support. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 Roadmap
On Sun, Aug 7, 2011 at 12:40 PM, h3 wrote: > idk .. but I'll make one anyway. > > I whish there was something like this for django: > http://brainstorm.ubuntu.com/ > > Good news: the site's engine is Open Source > Bad news: it's ROR (http://bbyidx.com/) The fact that it is based in RoR is irrelevant. It's a tool. If it's the right tool for the job, We'd use it in a heartbeat. We're not idealogs -- we're perfectionists with deadlines :-) The *actual* bad news is that it's not connected to the Trac instance that we use as a project management tool. I don't see that adding a second issue tracking system in parallel to Trac would ultimately improve anything. This idea -- being able to +1 ideas and bugs -- is something that I have said *many* times that I would *love* to see. However, I'm not a Trac guru, and I don't have a whole lot of spare cycles to make it happen. I've been told that there are a bunch of 'voting' extensions available for Trac; if this is the case, all we need is for someone with the spare time to sort out the details. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [RFC] Improvements to better support implementing optimistic concurrency control
Essentially, you want a compare-and--swap instruction for a database?
Have you considered using memcached atomicity (add and cas) to handle this
kind of thing? It might get pretty elaborate, but with just a cursory
thought seems doable.
-peter
On Sat, Aug 6, 2011 at 9:59 PM, Steven Cummings wrote:
> Bad community member that I am, I jumped the gun and logged a ticket
> [1] on this one... anyway:
>
> Websites general avoid overly aggressive locking of data to deal with
> concurrency issues. When two users allowed to edit some data are
> simultaneously doing so, they're both allowed to do so and the
> last .save() wins (race condition). This is largely acceptable on the
> web as when two people are allowed to edit data they shouldn't be
> prevented to doing so. Further sites often have audit history (whether
> or not exposed to those users owning/managing the data) which tracks
> exactly what went on.
>
> However, some sites may wish to detect this situation and present the
> 2nd user with a page or the previous form stating that what they
> edited is now obsolete. Examples of situations where we don't want
> edits to be silently stomped are health and financial data. Bugzilla
> mid-air collisions are an example of an implementation in the wild.
>
> So, we could try to detect this by always re-querying the object just
> before update (or delete), but with sufficient traffic there is still
> the chance that two requests *think* they know the current state of it
> in storage. This is where knowing rows modified, and/or having a
> precondition check would help. I've outlined the details on the
> ticket, but generally:
>
> * To ensure the object I'm saving is not stale, I might like to do
> Model.save_if(version=version), where I have an incremented version-
> field and save_if would compare the stored value (using something like
> an F('version')) against the given value. If the version was
> different, it should raise something like PreconditionFailed.
> * For delete()s, it might be nice to get rows-modified to know that
> the current request really did perform the delete. This is important
> in cases like using an OAuth auth code, where allowing multiple uses
> (deletes) of it would be a security problem.
>
> For both these cases, it would also be useful to either get rows-
> modified (or precondition-met) in the post-save/delete signal, or to
> somehow avoid those signals firing when no data was updated.
>
> I'm fully willing to hack on this and provide patches and/or use an
> experimental branch, just wanted to get some thoughts on it.
>
> [1] https://code.djangoproject.com/ticket/16549
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 Roadmap
On Sun, Aug 7, 2011 at 5:25 PM, Russell Keith-Magee wrote: > On Sun, Aug 7, 2011 at 12:40 PM, h3 wrote: > > idk .. but I'll make one anyway. > > > > I whish there was something like this for django: > http://brainstorm.ubuntu.com/ > > > > Good news: the site's engine is Open Source > > Bad news: it's ROR (http://bbyidx.com/) > > The fact that it is based in RoR is irrelevant. It's a tool. If it's > the right tool for the job, We'd use it in a heartbeat. We're not > idealogs -- we're perfectionists with deadlines :-) > > The *actual* bad news is that it's not connected to the Trac instance > that we use as a project management tool. I don't see that adding a > second issue tracking system in parallel to Trac would ultimately > improve anything. > > This idea -- being able to +1 ideas and bugs -- is something that I > have said *many* times that I would *love* to see. However, I'm not a > Trac guru, and I don't have a whole lot of spare cycles to make it > happen. > > I've been told that there are a bunch of 'voting' extensions available > for Trac; if this is the case, all we need is for someone with the > spare time to sort out the details. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > "idealogs" I'm about 100% sure that's not the word you wanted, but it's awesome. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 Roadmap
On Mon, Aug 8, 2011 at 9:44 AM, Alex Gaynor wrote: > > > On Sun, Aug 7, 2011 at 5:25 PM, Russell Keith-Magee > wrote: >> >> On Sun, Aug 7, 2011 at 12:40 PM, h3 wrote: >> > idk .. but I'll make one anyway. >> > >> > I whish there was something like this for django: >> > http://brainstorm.ubuntu.com/ >> > >> > Good news: the site's engine is Open Source >> > Bad news: it's ROR (http://bbyidx.com/) >> >> The fact that it is based in RoR is irrelevant. It's a tool. If it's >> the right tool for the job, We'd use it in a heartbeat. We're not >> idealogs -- we're perfectionists with deadlines :-) >> >> The *actual* bad news is that it's not connected to the Trac instance >> that we use as a project management tool. I don't see that adding a >> second issue tracking system in parallel to Trac would ultimately >> improve anything. >> >> This idea -- being able to +1 ideas and bugs -- is something that I >> have said *many* times that I would *love* to see. However, I'm not a >> Trac guru, and I don't have a whole lot of spare cycles to make it >> happen. >> >> I've been told that there are a bunch of 'voting' extensions available >> for Trac; if this is the case, all we need is for someone with the >> spare time to sort out the details. >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > "idealogs" I'm about 100% sure that's not the word you wanted, but it's > awesome. Oops -- ideolog. Or ideologue if you're spelling it right :-). Neologistic homophones are AWESOME %-) Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 Roadmap
Hi, On Monday, August 8, 2011 2:19:07 AM UTC+2, Russell Keith-Magee wrote: > > someone who has the spare time to manage the release process. That's > been me for the last two releases; I'm fairly certain I won't have the > spare cycles to make it three in a row. > Is the release process documented somewhere and could someone from outside of the core team step in to help out here? Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/yblqbZc_m24J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
