|
Posted
8 months
ago
Today, a batch of Ardunino compatible nixie tub boards arrived from China. I heard about these a week ago on Professor Craven's blog and immediately ordered four of them for myself. For those that don't know what a Nixie Tube is, Wikipedia has the
... [More]
answers. As it says:
A Nixie tube is an electronic device for displaying numerals or other information. The glass tube contains a wire-mesh anode and multiple cathodes, shaped like numerals or other symbols. Applying power to one cathode surrounds it with an orange glow discharge. The tube is filled with a gas at low pressure, usually mostly neon and often a little mercury or argon, in a Penning mixture. Basically, Nixie tubes were used before LED displays were invented to do alphanumeric displays on equipment, especially in the various militaries of the world. The numeric only ones, such as what people use for clocks, have the numbers 0 through 9 individually outlined, one on top of the other, with each one lit in turn as needed. If you've watched old 1960s science fiction movies, you've undoubtedly seen a Nixie tub display on a computer or piece of "high tech" equipment. Professor Craven put a little video up yesterday of his tubes plugged into a board: I have a flickr photo set of one of the boards as received. Like Professor Craven, I plan on using them for a clock of sorts. More specifically, I plan on making a meditation timer for shits and grins. The idea is that I will laser cut a box at Ace Monster Toys to hold the hardware. I'll put an arduino and the Nixie tube boards in it, with two or more of the tubes poking out, as a display. I'll probably use two to signify minutes. I'm then thinking of adding two solenoids that go out the sides, underneath to small metal bars or rods and a few buttons. The idea is that you can set a series of times on the clock, like a sitting period and then a walking period for meditation (or a series of these as pairs) via the buttons. When each period ends, the solenoids will fire a series of times (like two or three or one, depending on what just ended or if we're completely done), which will strike the metal bars, triggering a chime. This is similar to the "Zen Alarm Clock" that has been around forever but a bit less new agey and more…something. This seems both appropriately hackerish or geeky and appropriately Buddhist, in some sense. [Less] |
||||||
|
Posted
8 months
ago
by
nore...@blogger.com (K Lars Lohn)
I'm traveling home from Djangocon in Washington DC. Since I refuse to surrender my constitutional rights in order to be allowed to ride in an airplane, I'm stuck on the ground. However, I treated this as an opportunity, I trucked my Harley to
... [More]
Tennessee and the availed my self of some seriously nice motorcycling in the eastern states both to and from DC. I'm now on the return truck part of the trip with a couple Harleys in tow.
My riding buddy, Mike, had a mission. His neighbor, Rosie, on hearing that he was to be traveling in the South, requested that he get her some Sorghum Syrup. Not knowing where to find it, we asked our hosts Bill and Peggy in Hohenwald for a clue. They immediate suggested Cane Creek Market a small rural store on an obscure road in Tennesse. It was only a few miles away from Hohenwald, so we decided to stop by as we started our long journey back to the West Coast. It really seems to be in the middle of nowhere. I hadn't planned on going in, but Mike was taking a long time, so I decided to see what was up. The only word that I can come up with to describe the place is “enchanting”. The store is a showcase of locally produced goods and all the components to make them. I saw no national brands. The shelves were stocked with bags, tubs and jars all sporting labels likely printed right there in the store. While I'm not a stranger to Costco, I generally prefer to shop at my local organic coop. I doubt that even my politically correct Oregon coop market has as many locally sourced items on its shelves. I encountered a bearded man taking inventory and commented on my delight in visiting his store. I introduced myself and I into a conversation with Vance Coblentz, the current owner: “This place was established in 1990, approx. 22 yrs. ago. Originally it had been a farmers market at another location. The business was then moved to the current place by the previous owner. It was run by a Mennonite man, same as me...” “I had originally moved in from Ohio to take a job at the local lumber yard, which I did. I've always thought I'd like to do something like this, operating a store, but it never seemed to work out until 2 years after we moved here. I have a small family consisting of: my wife, 9 mo. old son, and a 15 mo. old foster daughter that we will be adopting on Sept. 24 of this year. So, am hoping this will be a greatthing to bring up my children on.” About the mix of his clientele, Vance said, “I would say about 35% of my customers are local. The rest would either be tourists, out-of-state friends and relatives of the locals, and people from surrounding cities like Memphis and Nashville. The "locals", as they are known, would consist of a mixture of Amish-Mennonite, Mennonite, and a few others in between.” Between the two of us, Mike and I bought about eighty bucks worth of snacks, pickled or dried vegetables, and, yes, sorghum syrup. So this is my advice, if you're traveling I40 between Nashville and Memphis, take the extra forty minutes: get off the freeway at exit 143, head south on TN13 for about 15 miles, turn left onto TN438 and you'll find the Cane Creek Market on the right in about two miles. It is well worth the trip. [Less] |
||||||
|
Posted
8 months
ago
Tim O'Brien's mini-quadcopter
Last night, we had our new semi-regular small open house at Ace Monster Toys. One of our members, Mark, had recently met another fellow, Tim O'Brien, and invited him to come by. While playing with a tiny toy ... [More] (indoor) quadcopter that I picked up this week, Tim showed his scratch built mini-quadcopter. I gather from what he said (and what I see on his site), that he's been building and creating quads for couple of years now. Most of the ones that you see are much larger, roughly 18 inches or so across and actually kind of awe inspiring if you turn them on in an enclosed space (which I don't recommend). Some of us have been interested in mini or micro-quads because we'd like to be able to play with them inside of places like AMT or our homes and not just take our big flying lawnmowers to the park to fly. The fact that Tim had hacked a relatively nice one together of just that size made it rather fun to see and it was a nice coincidence that he showed up and brought it. Tim has a post on what I assume is a previous iteration of the same design, in which he built his own platform for it for a class. I took a brief phone video of him flying his in the space (pardon my shaking cam hands) that gives a sense of the size of his quadcopter: Since AMT has one member who regularly flies quads and something like four or five of us that have been building them but never really flown them, having someone with a few years of experience, including building from scratch, would be nice. (My big quad is fully built but completely uncalibrated for flight, for example, and Tim offered to help me calibrate it quickly.) I've asked Tim to come do a short presentation or introduction to quadcopters for some evening. We're going to figure out schedules so he can come to AMT for an hour or so some evening and talk about his work. [Less] |
||||||
|
Posted
8 months
ago
It seems, somehow, for the last few months, I've been working on layout. I'm not quite sure how it happened, as anyone who's spoken to me or follows me on Twitter would know that I have a very healthy fear of the Gecko layout code. I still have that
... [More]
fear, but I'd like to think now that it's coupled with a tiny amount of understanding; understanding that has, dare I say it, even let me have fun while working on this code!
Those of you that have used browsers on mobile phones (all of you?), especially not the very latest phones, may be familiar with an annoying problem. That is, elements that have position:fixed in their style tend to jump around the place like they've had too much coffee. You commonly see this on sites that have a persistent bar at the top or bottom of the page, or floating confirmation notifications, things like this. Brad Frost wrote about this far more eloquently than I could here. This has always annoyed me, especially after learning more about how browsers work. Certainly in Gecko, we have all of the context we need for this not to happen. It also ended up that this problem had been worked on long before I even joined Mozilla last year, so that made it doubly surprising that we suffered from this problem in all releases of Firefox Mobile. When I first came across this last year, I discovered that the support was already there in the old Firefox Mobile, but disabled by default due to it causing test failures. I was working on other things then, and wasn't at all acquainted with layout code, so I let it be. Revisiting it for the new, native Firefox Mobile though, these test failures didn't exist anymore. Enabling this basic support that would let position:fixed elements move and zoom with user input correctly was not too big a deal - just flip an environment variable and write a small amount of support code. This landed in Firefox 15 and is tracked in Bug 607417. Just this is enough for a lot of mobile sites to start using position:fixed (I'm looking at you, Twitter and Facebook!). This wasn't enough for me though. Around this time, Android 3.x (Honeycomb) tablets had been around for quite a while and the Galaxy Nexus with Android 4.0 (Ice-cream Sandwich) had just come out, both with even better support for position:fixed. Not to mention the iPhone, which has excellent support. A problem with our implementation in Firefox 15, is that anything fixed to the bottom or right of the screen, or anything that doesn't anchor to the top-left in any way, may become inaccessible after zooming in. In recent versions of the Android stock browser, not only do these remain accessible, but they zoom very smoothly too. Not wanting to be one-upped by what could be considered our main competition, I started to work on more comprehensive position:fixed support. This work was tracked in Bug 758620. When zooming in our browser, we don't change how the page is laid out, but fixed position elements are still rendered relative to the viewport. What we want (at least, for now) is for fixed position elements to lay out with respect to this viewport so that they always remain visible, and to transition smoothly between these states. To achieve this, I changed layout so that fixed position elements are laid out to what we call the scroll-port. When we zoom in, we change the scroll-port, otherwise you wouldn't be able to scroll to the bottom-right of the page, but this only changes scrolling behaviour and nothing else. This change also made it so that fixed-position children of the document would be relayed out when this scrollport was changed. This fixed the inaccessibility problem, but left nasty-looking transitions when zooming in. To fix the transitions was quite a bit more comprehensive and lead me down a long path of causing and fixing various layout bugs. When a page is rendered, the DOM tree is parsed into a frame tree, which better represents the layout of the page. This frame tree is then parsed into a display-list, which represents how to draw the page. This display-list is then optimised and parsed/drawn into a layer tree, which is the final representation before we composite it. There's cleverness to make sure that layers aren't recreated unnecessarily, but that's another subject for another time. We wanted to be able to annotate the layer tree so that when compositing, we have enough information to determine how to place fixed-position layers when zooming. This involved creating a new display-list item with the information about how the element is fixed (to the top? left? right? bottom?), and also that would guarantee that the items representing this element would end up on their own layer. Once this was done, code in the compositor was added to leverage this information and draw layers in the right place. This is an area that a lot of browsers have difficulty with, so it was a fun problem to work on. Try out a couple of my test-cases if you're interested, they expose how different browsers handle this situation, and in the case of a few of them, some bugs :) We're still not perfect, but we're better than we were before - and to my feeling, we're adequate now. This work landed in Firefox 16. So is there work left to do? Well, unfortunately, yes. I've just finished off support for fixed backgrounds and backgrounds with multiple fixed/non-fixed layers, and this will arrive in Firefox 18. This is tracked in Bug 786502. I also think that the best behaviour would be for fixed position elements to layout to whichever is largest of the CSS viewport or the scroll-port, and for scrolling to be within the CSS viewport and push the edges when you reach them. I'm told this is what happens in IE10 on Windows 8, and is similar (but slightly better) to what gets done in Safari on iOS. I think it's about time for a break from this particular feature for me, though. [Less] |
||||||
|
Posted
8 months
ago
by
nos...@example.com (Dustin J. Mitchell)
For a project at Mozilla that involves re-imaging hundreds of mobile devices, we want to gather logs in a database for failure analysis. Mobile devices fail all the time -- not sure if you knew that.
We'll probably end up with 1,000-10,000 ... [More] log entries per day. We'd like to expire them on a relatively aggressive schedule -- no need for historical analysis at this level. So that means not only a lot of inserts, but a lot of deletes. We're using MySQL as the database backend, and MySQL doesn't do well with deletes - it just marks the row as deleted, but doesn't reclaim the space, and in fact doesn't even remove the row from consideration in queries. So if you blindly insert and delete in a table, MySQL will eat disk space and get progressively slower. One fix to this is to optimize the table periodically. However, this requires a full lock of the table for the duration of the optimize, which can be quite a while. We dont' want to cause a backup of production tasks while this is going on. The other option is to partition the table. A partitioned table is basically a set of tables (partitions) with the same columns, organized to look like a single table. There's a partitioning function that determines in which partition a particular row belongs. There are a few advantages. Each partition is a fraction of the size of the whole table, so inserts are quicker (once the appropriate table is determined). The query engine can use "partition pruning" to ignore partitions that could not hold rows relevant to the query. Finally, dropping an entire partition at once is a very simple operation, and doesn't leave any garbage that needs to be optimized away. For logs, we want to partition by time, in this case with one partition per day. Most of the "get the logs" queries will use a limited time range, invoking query pruning and allowing a quick response. The tricky part is, the DB server does not automatically create and destroy partitions. We need to do that. It's pretty straightforward with stored procedures, though. Here's the resulting SQL to create the logs table: DROP TABLE IF EXISTS logs; CREATE TABLE logs ( -- foreign key for the board board_id integer not null, ts timestamp not null, -- short string giving the origin of the message (syslog, api, etc.) source varchar(32) not null, -- the message itself message text not null, -- indices index board_id_idx (board_id), index ts_idx (ts) ); -- -- automated log partition handling -- DELIMITER $$ -- Procedure to initialize partitioning on the logs table DROP PROCEDURE IF EXISTS init_log_partitions $$ CREATE PROCEDURE init_log_partitions(days_past INT, days_future INT) BEGIN DECLARE newpart integer; SELECT UNIX_TIMESTAMP(NOW()) INTO newpart; SELECT newpart - (newpart % 86400) INTO newpart; -- round down to the previous whole day -- add partitions, with a single partition for the beginning of the current day, then -- let update_log_partitions take it from there SET @sql := CONCAT('ALTER TABLE logs PARTITION BY RANGE (UNIX_TIMESTAMP(ts)) (' , 'PARTITION p' , CAST(newpart as char(16)) , ' VALUES LESS THAN (' , CAST(newpart as char(16)) , '));'); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; -- do an initial update to get things synchronized call update_log_partitions(days_past, days_future); END $$ -- Procedure to delete old partitions and create new ones around the current date DROP PROCEDURE IF EXISTS update_log_partitions $$ CREATE PROCEDURE update_log_partitions(days_past INT, days_future INT) BEGIN DECLARE part integer; DECLARE newpart integer; DECLARE earliest integer; DECLARE latest integer; -- add new partitions; keep adding a partition for a new day until we reach latest SELECT UNIX_TIMESTAMP(NOW()) 86400 * (days_future 1) INTO latest; createloop: LOOP -- Get the newest partition (PARTITION_DESCRIPTION is the number from VALUES LESS THAN) -- partitions are named similarly, with a 'p' prefix SELECT MAX(PARTITION_DESCRIPTION) INTO part FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME='logs' AND TABLE_SCHEMA='imagingservice'; IF part < latest THEN -- note part cannot be NULL, as there must be at least one partition SELECT part 86400 INTO newpart; SET @sql := CONCAT('ALTER TABLE logs ADD PARTITION ( PARTITION p' , CAST(newpart as char(16)) , ' VALUES LESS THAN (' , CAST(newpart as char(16)) , '));'); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; ELSE LEAVE createloop; END IF; END LOOP; -- now, deal with pruning old partitions; select the minimum partition -- and delete it if it's too old SELECT UNIX_TIMESTAMP(NOW()) - 86400 * (days_past 1) INTO earliest; purgeloop: LOOP -- Get the oldest partition SELECT MIN(PARTITION_DESCRIPTION) INTO part FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME='logs' AND TABLE_SCHEMA='imagingservice'; IF part < earliest THEN SET @sql := CONCAT('ALTER TABLE logs DROP PARTITION p' , CAST(part as char(16)) , ';'); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; ELSE LEAVE purgeloop; END IF; END LOOP; END $$ DELIMITER ; -- initialize the partitioning CALL init_log_partitions(14, 1); -- and then update every day (this can't be set up in init_log_partitions) DROP EVENT IF EXISTS update_log_partitions; CREATE EVENT update_log_partitions ON SCHEDULE EVERY 1 day DO CALL update_log_partitions(14, 1); A few notes here. First, the table is created without any partitions. This is because I don't know a priori which partitions it should have, and it's easier to get code to figure that out than do it myself. That's what the initlogpartitions function does. The updatelogpartitions function looks at the current time and makes sure there are enough partitions for the future, and drops partitions too far in the past. Finally, a MySQL event is set up to update the partitions daily. You'll need to enable the event scheduler globally to get this to run: set global event_scheduler=on; [Less] |
||||||
|
Posted
8 months
ago
by
gerv
The FSF has a Free Software Directory.
Firefox is not in it, although Thunderbird is. It would be great if someone from our community could write and submit an entry for Firefox. |
||||||
|
Posted
8 months
ago
by
nore...@blogger.com (Pedro Alves)
This has been a long standing blog post. CGG has been around for ages now, it's even in Pentaho platform core, and only a few knew about it.
CGG stands for Community Graphics Generator. Although it even has it's own homepage, I never had ... [More] the chance to blog about it. It's a somewhat hardcore plugin: it's basically able to execute on the server side custom scripts (java / javascript) that outputs images that can be used in external systems. One of the most useful use cases is to be able to export CCC charts to images (png or svg) - either to allow a user the ability to download it, or to include it in Pentaho Reporting or any other of those tools Here's an example of how it works. Imagine you develop for your users a great looking dashboard, almost as good looking as one of the UIs we develop :) : (This was the dashboard we developed in a recent Ctools training course in Orlando, Pentaho headquarters) As you can see, we went to some extent, exploring CCC capabilities, to fine tune the charts. Now we want to be able to use that line chart to PRD. Even though CGG does not have a UI and doesn't aim to be user friendly, CDE has a way to make the bridge to it, using some hidden features. Going straight to the point. In CDE, press shift-G. That will open the CGG window (as a side reference, press shift-? to see other very useful keyboard shortcuts): If you ever used this feature before, you'll notice this screen is a little different. We just added some more features, namely the ability to automatically get the url that generates that image from the outside - even I always struggled to find the right url. This is already available in the dev builds and will be released in the next stable version. You'll be able to see that you can set some options there, namely the outputType, that currently can be either png or svg and you may need to change the server url if are developing in a sandbox and want to publish it to a server. I actually thought svg support was broken in PRD but just tested it and that seems to be fixed, so take advantage of that feature. One other thing to note is that you must take care of authentication. Either you pass the extra arguments &userid=joe&password=password or you allow that url to be accessible with no password, or whatever. If you save your dashboard and try that url, this is what you'll get: This is what CGG is all about, and there's tons of engineering work underneath to allow this "simple step" to work with just one keystroke. Now it's gets very obvious what to do. Open PRD, add an image component, and put that url (don't forget authentication) You'll also want to check the blog post I did a while back about using CDA datasources in PRD. In the meanwhile, in recent versions of PRD (4.5 and above) you don't need to download the CDA datasources, all you need to do is enable the experimental features in Edit -> Preferences -> General -> Enable Experimental Features. To render this report from the server, you'll need to copy to pentaho/WEB-INF/lib/ the file pentaho-reporting-engine-classic-extensions-cda-*.jar that you'll find in PRD library directory. There's another feature of CGG. You can pass parameters to the query, by adding ¶mParameterName=ParameterValue to the url. And that can be exposed from PRD too. Just create a prompt the usual way. On my sample, the parameter is called a month, and since the query is already on the dashboard too, I just need to select it to build the prompt in the prpt. However, in order to make the call with the new parameter, we can't use the image component anymore, and use the image-field instead. For that, we need to create a formula that will build that url. Here's the sample formula I used: ="http://127.0.0.1:8080/pentaho/content/cgg/Draw?script=/SyncOrlando/Lab12/lineChart.js&outputType=png&userid=joe&password=password¶mmonthParameter="&URLENCODE([month]) The URLENCODE function allows us to be sure that our parameters will reach the server properly. In the end, we should have a report looking like this: Advanced topic: If you make reports with a lot of charts (you can even have cgg rendering a chart per line) you'll soon find out that your report starts to take a really long time to render. There's an explanation for it: PRD does a lot of passes to better determine the final layout. Since CGG doesn't support the HEAD request method, PRD won't get the appropriate info regarding cache, resulting in a bunch of requests for the image. Fortunately, Thomas Morgner allowed is a workaround to this issue, by changing a behavior in libloader. In your loader.properties file (located in WEB-INF/classes for the server or create it under prd/resources dir for the report designer) add the following lines: # Controls the minimum time between HEAD requests regardless of # the date -headers given by the response object. org.pentaho.reporting.libraries.resourceloader.config.url.FixedCacheDelay=500000 # Fixes the date headers by simply using Date.now() as mod-date. # This will break the HTTP specs and thus it is disabled by default. org.pentaho.reporting.libraries.resourceloader.config.url.FixBrokenWebServiceDateHeader=trueThis particular feature will be available in Pentaho Reporting 3.9.1 (or you'll have to compile your own) And this is what it looks from the Pentaho BI server: Cheers -pedro [Less] |
||||||
|
Posted
8 months
ago
by
Chris
I spent the last weekend in Warsaw, Poland to attend the Mozcamp 2012 meeting with Mozillians from around the world to see where the project is going and how we can best use the resources we have.
In essence: it was a blast. You can see at ... [More] the very packed schedule that we covered a lot of topics and got each other up to speed on the things we are doing for Mozilla. All attendees of Mozcamp were asked to set themselves a mission for the weekend to use our time the most effectively. Mine was the following: Meet 10 already existing or new Evangelism Reps and deliver a great training to get them started. I easily achieved that mission but I was a bit disappointed when I saw that we only had an hour of training rather than the originally planned 2 hours. I partnered with the man who got me excited about Mozilla in the first place, Tristan Nitot, to introduce the attendees of our training to the Mozilla mission and get them excited about presenting and producing posts, screencasts and code examples. When I plan trainings, I have something for every minute of it and the main trick is to make the attendees do the work. This is not because I am lazy, but as humans we tend to retain information we found out by ourselves much better than things we just listened to. The plan for this session was: 00.00 – 05.00 – Introduction and aim of the course “By the end of this training you know where to find information to promote Mozilla in person and on the Internet”05.00 – 10.00 – Introduction of different ways to promote Mozilla: BloggingCreating demosVideos / ScreencastsSpeaking10.00 – 26:00 Walkaround with four whiteboards What makes a good blog post?What is important in good tech demos?What inspires you in good videos/screencasts?What makes a talk great?26:00 – 36:00 Preparing group presentations36:00 – 52:00 Group presentations on all the results52:00 – 60:00 Joint presentation Chris/Tristan on the resources we have. The idea is to have four groups and make them each for 4 minutes collect information on the topic and then shift around, so in the end each group has their own findings and those of others to use in their presentations. So much for the theory – 10 people had signed up for our session which is a good size. When our session started though, about 45 showed up and we had neither the whiteboards in place or enough chairs, so we had to get them from other rooms. The beauty of the 4 group training is that it scales so in the end we had groups of 12 people which made for longer discussions and appointing speakers but it worked out. Incredibly well, actually – I am always amazed how you can make a group of people work very concentrated together when you set a simple goal and a fixed time frame. See the full intensity of it in this video (fox hat included): As there was a lot more interest in evangelism training Shezmeen Prasad and me thought it a good idea to offer another, after-mozcamp session in the hotel. We set it on Sunday at 8 – 10pm after two days of a packed schedule and again wondered if anyone would show up. They did, 35 of them this time. As the room layout did not really lend itself to a training in the style of the other we spent the two hours with open Q&A about speaker tips and tricks and watching a few talks analysing how the speakers made them great – again in a group information gathering and presenting session. As a follow-up (and as this was a common request) I cleaned up the HTML5 slide deck we have for evangelism reps and created two screencasts on how to get the slide deck and present in it and how to write your own slides. How to get the Mozilla slide deck and present it on YouTube. Creating slides in shower on YouTube. You can find out more about what the reps do on the Evangelism Reps Wiki or by visiting us on Facebook. It was exhausting, but very much worth it! I had a lot of fun meeting all the reps and look forward to all the material we’ll create together. [Less] |
||||||
|
Posted
8 months
ago
by
Benjamin Kerensa
I have focused a lot of time lately towards reviewing products that will have a positive impact on the environment and consumer budgets. I recently reached out to Phillips, Sylvania, GE and LightKiwi to sample some of their LED Bulbs for a review and
... [More]
I hope to highlight the differences of these LED lights so here is the results.
The LED Bulbs Phillips AmbientLED The AmbientLED is a an A19 replacement bulb made by Phillips who have been innovative in the field of LED Technology for years now. The AmbientLED is rated as 60-watt replacement and consumes 12.5 watts of electricity while producing 64 lumens per watt for a total of 800. The AmbientLED produces an amazingly bright and soft color with a 2700k lighting index and is suitable for overhead ceiling fixtures and lamps and will give rooms plenty of light without being overwhelming, all while staying at a cool temperature of 108 Fahrenheit. I really enjoyed the unique design of the Phillips AmbientLED which looks very futuristic versus plain and the size was compact. Sylvania UltraLED The UltraLED is A19 replacement bulb made by Sylvania-Osram. Like most LED’s lasts 25 times longer than an incandescent bulb. The UltraLED uses only 12 watts of power while producing 810 lumens or 67 lumens per watt which is amazingly efficient for a LED bulb. The output color for this bulb is Warm White (2700k) and the operating temperature I found was 105 Fahrenheit. I enjoyed the Sylvania but found it a bit bulky in size and heavier than other LED bulbs on the market, however it used .5 less watts than the Phillips AmbientLED. LightKiwi A19 I had the opportunity to check out LightKiwi’s A19 (LK-6A19E26(D)-27) which beat its competitors in consuming only 6-7 watts while producing 2700k coloring and being a 50-watt equivelent. I really liked the color of the Kiwi Light and the construction was just as solid as its competitors. I really enjoyed the Kiwi the light was perfect in most settings and the energy savings far exceeded the competitors bulbs. When it came down to the energy savings this bulb really blew everything else out of the water! GE 13 Watt A19 General Electric (GE) provided me with their 13-watt A19 which consumes 13-watts per hour is a 60-watt equivelant providing 800 lumens at 64 lumens per watt with a white color temp of 3000.I did not like the metal prong like fins because I felt they were just in the way and added extra weight to the bulb. The Verdict I believe the Sylvania and Kiwi bulbs provide the best incentives in savings and design for most consumers looking to replace their incandescent or CFL A19′s. I am hopeful to see a Phillips LED bulb that uses even less watts in the future. As for GE, I think they need to re-think the prong design while also getting the watt usage instead down to the 12-12.5 standard, which seems to be the most common energy use factor among LED light bulbs. I will note that I hope to review a bulb by Feit and GeoBulb in the future but at the time of writing this review I had not heard back from either manufacturer. When doing this review I also looked at a number of places to purchase bulbs and looked at reviews of other users and one concern I must urge people to pay attention to is make sure the bulb is genuinely UL certified that is it has a Underwriters Laboratory certification and marking on its packaging. If the bulb lacks UL certification there is always a potential of fire risk and there have been reports of people buying cheap LED bulbs directly from China on sites like eBay and having them catch fire or smoke due to faulty soldering or other causes. In closing I want people to understand that LED’s are really picking up on the consumer market and will save you a bundle over time with a bulb paying for itself in the first year or two and then saving you a more over the years. Additionally LED’s operate at a lower temperature than CFL’s and Incandescent’s which means a lower cooling bill in the summer and reduce heat in fixtures which pose a fire hazard in older homes. Whether you buy now or later I do not anticipate major price changes in the LED market and there are already bulbs that are as cheap as $17-20 per bulb which is amazing consider cost savings. For updates on future reviews and blog posts do not hesitate to subscribe to my RSS feed or use my e-mail subscribe at the top right hand side of my blog! I look forward to hearing from you about your LED Bulb experiences in my comment section below! The post LED Lights Reviewed 2012 appeared first on Benjamin Kerensa dot Com. [Less] |
||||||
|
Posted
8 months
ago
by
John
tl;dr: We’ve had a lot of infrastructure changes go live in the last 2-3 weeks, so now build and test wait times are MUCH better. The changes made were:
1) Turn off obsolete or broken jobs. 2) Re-image some linux32/linux64/win32 ... [More] machines as extra Win2008 (64bit) build machines. 3) Enable pymake in production 4) Turn on more tegras 5) Re-imaging 40 OSX10.5 test machines as 20 WinXP and 20 Win7 test machines. After all the recent meetings and newsgroup posts, I thought it useful to followup with a quick summary of the last few weeks of behind the scenes work on how RelEng infrastructure is handling the increased checkin load, as well as the increased number of builds/tests per checkin. Oh, and its worth noting for the record that all these changes have been done without needing a downtime. 1) Turn off obsolete or broken jobs. This is not glamorous work, but there were lots of these and it had a massive impact in terms of reducing load in some areas, which allowed us to reshuffle machines to other areas. Specifically, we’ve disabled: perma-orange/red test suites android-xul tests, no longer needed standalone talos v8 test suite, now included in the dromaeojs suite B2G-on-gingerbread builds. (B2G-on-gingerbread builds were intentionally broken as part of setting up B2G-on-icecreamsandwich builds but left running hidden on tbpl.m.o. This was bad because a) B2G-on-gingerbread builds continued to waste CPU cycles and b) having broken B2G-on-gingerbread builds caused B2G IceCreamSandwich nightly builds to not be run because automation thought that there were no good/green changesets for B2G. Disabling the broken B2G-on-gingerbread builds fixed both these issues. (bug#780915). Disabled osx10.5 tests on mozilla-central, related project branches and try, because FF17 no longer supports osx10.5. However, we still need some osx10.5 machines in order to run osx10.5 tests for mozilla-aurora, mozilla-beta, mozilla-release and ESR. There is still an open question about linux32/64 builds/tests. Can we reduce our linux test capacity on one architecture to use these as test machines for other OS? From the thread it seems like the preference would be to turn down/off 32-bit builds/tests, but if you are interested, please respond in the dev.planning thread. Of course, if you know of other builds or tests that aren’t used, or are perma-red/orange, let RelEng or Sheriff know and we can disable them until they can be fixed! Tests still to be disabled are tracked in bug#784681 2) Re-image some linux32/linux64/win32 machines as extra Win2008 (64bit) build machines. linux32/linux64 builds continue to migrate to AWS, which frees up linux32/linux64 build machines for reimaging as win2008 (64bit) build machines. This requires changing desktop toolchain, so we have to be careful about not breaking binary compat, and needed to roll this change out on the trains. Details in bug#772446. As of today, we’ve increased from ~40 to 102 win2008 (64bit) build machines in production, with even more coming online soon. Details in bug#780022 and bug#784891. This is important because the Win2008 (64bit) machines are used to do both win32 *and* win64 builds. win32 l10n nightlies have code dependencies that require win32. Fixing this to run on win2008 (64bit) will free up even more win32 machines to convert to win2008 (64bit) builders. More details in bug#784848. 3) Enable pymake in production (bug# bug#593585). This reduced build time on windows significantly. Combined with the extra windows machines, this is all good. Coop blogged more details here, and if you like eyecandy, he even has even a cool graph showing reduced duration of builds! 4) Turn on more tegras 86 new tegras have now been added to our test pool, bringing our current total up to 284 tegras. bug#767456 5) Re-imaging 40 OSX10.5 test machines as 20 WinXP and 20 Win7 test machines. This increases us to 70 machines for WinXP and 70 machines for Win7x32, which helped improve WinXP, Win7 test wait times. We’ve still got lots to do, of course. After all, the faster our infrastructure can process builds and tests, the more checkins developers will do, which means the more builds and tests we will need to handle… but things are definitely better, and our numbers in dev.tree-management for the last two weeks shows that! [Less] |
||||||
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.